Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1553038 > unrolled thread

Re: [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM "santosh.shilimkar@oracle.com" <santosh.shilimkar@oracle.com> - 2017-01-06 20:00 +0100
    Re: [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM Santosh Shilimkar <santosh.shilimkar@oracle.com> - 2017-01-06 20:20 +0100
    Re: [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM Suman Anna <s-anna@ti.com> - 2017-01-06 20:20 +0100

#1553038 — Re: [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM

Hi Suman,

On 9/7/16 9:25 AM, Santosh Shilimkar wrote:
> On 9/7/2016 9:22 AM, Suman Anna wrote:
>> Hi Santosh,
>>
>> On 09/07/2016 11:11 AM, Santosh Shilimkar wrote:
>>> Hi Suman,
>>>
>>> On 9/1/2016 3:58 PM, Suman Anna wrote:
>>>> Hi,
>>>>
>>>> The Keystone 2 family of SoCs have an on-chip RAM called the
>>>> Multicore Shared Memory (MSM) RAM. This RAM is accessible through
>>>> the Multicore Shared Memory Controller (MSMC). This series represents
>>>> these on-chip RAMs as sram nodes so that the memory allocations
>>>> can be managed by the in-kernel mmio-sram driver.
>>>>
>>>> The first 4 patches adds the basic SRAM nodes on each of the SoCs,
>>>> and the last patch enables the generic on-chip SRAM driver for
>>>> keystone defconfig.
>>>>
>>> The series looks good in general but I would like to understand
>>> the users of this memory in kernel. Is that going to be posted
>>> as a follow up patch ? Is the Power controller going to make
>>> use of this SRAM for PM code ?
>>
>> Yes, the users will eventually follow. Power Controller code is not
>> gonna be using this SRAM, it has its own RAM. This memory is gonna be
>> split between various functional features like IPC, OPTEE integration,
>> we already have the Boot Monitor code using this. We will have the
>> memory split by either having static child nodes or drivers requesting
>> the memory using gen_pool API.
>>
> OK. Its good to add the code at least with one active user of it.
> Since this has to anyway wait for another merge window, please post the
> users of it so that I can pull the combined patchset.
>
Are you going to post new patchset or you dropped this series ?

If you want me to include it for next merge window, please post
refreshed patchset.

Regards,
Santosh

[toc] | [next] | [standalone]

#1553043

On 1/6/2017 11:10 AM, Suman Anna wrote:
> Hi Santosh,
>

>>> OK. Its good to add the code at least with one active user of it.
>>> Since this has to anyway wait for another merge window, please post the
>>> users of it so that I can pull the combined patchset.
>>>
>> Are you going to post new patchset or you dropped this series ?
>>
>> If you want me to include it for next merge window, please post
>> refreshed patchset.
>
> No, haven't dropped the series, will post it today. You prefer the
> series on -rc1 or -rc2, not that it makes a difference.
>
Right. rc1 is just fine.

Regards,
Sasntosh

[toc] | [prev] | [next] | [standalone]

#1553048

Hi Santosh,

> 
> On 9/7/16 9:25 AM, Santosh Shilimkar wrote:
>> On 9/7/2016 9:22 AM, Suman Anna wrote:
>>> Hi Santosh,
>>>
>>> On 09/07/2016 11:11 AM, Santosh Shilimkar wrote:
>>>> Hi Suman,
>>>>
>>>> On 9/1/2016 3:58 PM, Suman Anna wrote:
>>>>> Hi,
>>>>>
>>>>> The Keystone 2 family of SoCs have an on-chip RAM called the
>>>>> Multicore Shared Memory (MSM) RAM. This RAM is accessible through
>>>>> the Multicore Shared Memory Controller (MSMC). This series represents
>>>>> these on-chip RAMs as sram nodes so that the memory allocations
>>>>> can be managed by the in-kernel mmio-sram driver.
>>>>>
>>>>> The first 4 patches adds the basic SRAM nodes on each of the SoCs,
>>>>> and the last patch enables the generic on-chip SRAM driver for
>>>>> keystone defconfig.
>>>>>
>>>> The series looks good in general but I would like to understand
>>>> the users of this memory in kernel. Is that going to be posted
>>>> as a follow up patch ? Is the Power controller going to make
>>>> use of this SRAM for PM code ?
>>>
>>> Yes, the users will eventually follow. Power Controller code is not
>>> gonna be using this SRAM, it has its own RAM. This memory is gonna be
>>> split between various functional features like IPC, OPTEE integration,
>>> we already have the Boot Monitor code using this. We will have the
>>> memory split by either having static child nodes or drivers requesting
>>> the memory using gen_pool API.
>>>
>> OK. Its good to add the code at least with one active user of it.
>> Since this has to anyway wait for another merge window, please post the
>> users of it so that I can pull the combined patchset.
>>
> Are you going to post new patchset or you dropped this series ?
> 
> If you want me to include it for next merge window, please post
> refreshed patchset.

No, haven't dropped the series, will post it today. You prefer the
series on -rc1 or -rc2, not that it makes a difference.

regards
Suman

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web