[Sound-open-firmware] [PATCH] apl: memory: expand number of 256 Bytes block to be 64
The 256 Bytes block are used frequently for component new, 16 is not enough for GP-MRB multiple SSPs/pipelines support, here expand it to be 64.
Signed-off-by: Keyon Jie yang.jie@linux.intel.com --- Test with: APL-MRB with tdf8532 codec Linux topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f SOF master: 48a61423f6c2d2bcf5fad854a9b3d37dfb43b546 Tool master: 7ee114d2ed822a0dbfc0dc3a37fd5c4977e00be8 --- src/platform/apollolake/include/platform/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/platform/apollolake/include/platform/memory.h b/src/platform/apollolake/include/platform/memory.h index e7f3ee3..652db96 100644 --- a/src/platform/apollolake/include/platform/memory.h +++ b/src/platform/apollolake/include/platform/memory.h @@ -159,7 +159,7 @@ #define HEAP_RT_COUNT32 128 #define HEAP_RT_COUNT64 64 #define HEAP_RT_COUNT128 32 -#define HEAP_RT_COUNT256 16 +#define HEAP_RT_COUNT256 64 #define HEAP_RT_COUNT512 8 #define HEAP_RT_COUNT1024 4
On Thu, 2018-05-31 at 16:05 +0800, Keyon Jie wrote:
The 256 Bytes block are used frequently for component new, 16 is not enough for GP-MRB multiple SSPs/pipelines support, here expand it to be 64.
Signed-off-by: Keyon Jie yang.jie@linux.intel.com
Test with: APL-MRB with tdf8532 codec Linux topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f SOF master: 48a61423f6c2d2bcf5fad854a9b3d37dfb43b546 Tool master: 7ee114d2ed822a0dbfc0dc3a37fd5c4977e00be8
src/platform/apollolake/include/platform/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/platform/apollolake/include/platform/memory.h b/src/platform/apollolake/include/platform/memory.h index e7f3ee3..652db96 100644 --- a/src/platform/apollolake/include/platform/memory.h +++ b/src/platform/apollolake/include/platform/memory.h @@ -159,7 +159,7 @@ #define HEAP_RT_COUNT32 128 #define HEAP_RT_COUNT64 64 #define HEAP_RT_COUNT128 32 -#define HEAP_RT_COUNT256 16 +#define HEAP_RT_COUNT256 64 #define HEAP_RT_COUNT512 8 #define HEAP_RT_COUNT1024 4
Can you check this does not overflow the HEAP into another section. We could also look at deprecating 1024 & 512 and giving this space up to the others.
Liam
Hi Liam,
You may missed this one, ping.
Thanks, ~Keyon
-----Original Message----- From: sound-open-firmware-bounces@alsa-project.org [mailto:sound-open- firmware-bounces@alsa-project.org] On Behalf Of Keyon Jie Sent: Thursday, May 31, 2018 4:06 PM To: sound-open-firmware@alsa-project.org Cc: Keyon Jie yang.jie@linux.intel.com Subject: [Sound-open-firmware] [PATCH] apl: memory: expand number of 256 Bytes block to be 64
The 256 Bytes block are used frequently for component new, 16 is not enough for GP-MRB multiple SSPs/pipelines support, here expand it to be 64.
Signed-off-by: Keyon Jie yang.jie@linux.intel.com
Test with: APL-MRB with tdf8532 codec Linux topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f SOF master: 48a61423f6c2d2bcf5fad854a9b3d37dfb43b546 Tool master: 7ee114d2ed822a0dbfc0dc3a37fd5c4977e00be8
src/platform/apollolake/include/platform/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/platform/apollolake/include/platform/memory.h b/src/platform/apollolake/include/platform/memory.h index e7f3ee3..652db96 100644 --- a/src/platform/apollolake/include/platform/memory.h +++ b/src/platform/apollolake/include/platform/memory.h @@ -159,7 +159,7 @@ #define HEAP_RT_COUNT32 128 #define HEAP_RT_COUNT64 64 #define HEAP_RT_COUNT128 32 -#define HEAP_RT_COUNT256 16 +#define HEAP_RT_COUNT256 64 #define HEAP_RT_COUNT512 8 #define HEAP_RT_COUNT1024 4
-- 2.14.1
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 2018年05月31日 19:51, Liam Girdwood wrote:
On Thu, 2018-05-31 at 16:05 +0800, Keyon Jie wrote:
The 256 Bytes block are used frequently for component new, 16 is not enough for GP-MRB multiple SSPs/pipelines support, here expand it to be 64.
Signed-off-by: Keyon Jie yang.jie@linux.intel.com
Test with: APL-MRB with tdf8532 codec Linux topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f SOF master: 48a61423f6c2d2bcf5fad854a9b3d37dfb43b546 Tool master: 7ee114d2ed822a0dbfc0dc3a37fd5c4977e00be8
src/platform/apollolake/include/platform/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/platform/apollolake/include/platform/memory.h b/src/platform/apollolake/include/platform/memory.h index e7f3ee3..652db96 100644 --- a/src/platform/apollolake/include/platform/memory.h +++ b/src/platform/apollolake/include/platform/memory.h @@ -159,7 +159,7 @@ #define HEAP_RT_COUNT32 128 #define HEAP_RT_COUNT64 64 #define HEAP_RT_COUNT128 32 -#define HEAP_RT_COUNT256 16 +#define HEAP_RT_COUNT256 64 #define HEAP_RT_COUNT512 8 #define HEAP_RT_COUNT1024 4
Can you check this does not overflow the HEAP into another section. We could also look at deprecating 1024 & 512 and giving this space up to the others.
this change will increase HEAP_RUNTIME_SIZE with 4KB, and HEAP_BUFFER_BASE will be shifted 4KB upper also, actually HEAP_BUFFER_SIZE will be decreased 4KB at the end.
so no overflow here.
Thanks, ~Keyon
Liam
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 2018年06月07日 16:06, Keyon Jie wrote:
On 2018年05月31日 19:51, Liam Girdwood wrote:
On Thu, 2018-05-31 at 16:05 +0800, Keyon Jie wrote:
The 256 Bytes block are used frequently for component new, 16 is not enough for GP-MRB multiple SSPs/pipelines support, here expand it to be 64.
Signed-off-by: Keyon Jie yang.jie@linux.intel.com
Test with: APL-MRB with tdf8532 codec Linux topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f SOF master: 48a61423f6c2d2bcf5fad854a9b3d37dfb43b546 Tool master: 7ee114d2ed822a0dbfc0dc3a37fd5c4977e00be8
src/platform/apollolake/include/platform/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/platform/apollolake/include/platform/memory.h b/src/platform/apollolake/include/platform/memory.h index e7f3ee3..652db96 100644 --- a/src/platform/apollolake/include/platform/memory.h +++ b/src/platform/apollolake/include/platform/memory.h @@ -159,7 +159,7 @@ #define HEAP_RT_COUNT32 128 #define HEAP_RT_COUNT64 64 #define HEAP_RT_COUNT128 32 -#define HEAP_RT_COUNT256 16 +#define HEAP_RT_COUNT256 64 #define HEAP_RT_COUNT512 8 #define HEAP_RT_COUNT1024 4
Can you check this does not overflow the HEAP into another section. We could also look at deprecating 1024 & 512 and giving this space up to the others.
this change will increase HEAP_RUNTIME_SIZE with 4KB, and HEAP_BUFFER_BASE will be shifted 4KB upper also, actually HEAP_BUFFER_SIZE will be decreased 4KB at the end.
Sorry, it should be (4 - 1) * 4KB = 12KB shift.
Thanks, ~Keyon
so no overflow here.
Thanks, ~Keyon
Liam
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Thu, 2018-06-07 at 16:23 +0800, Keyon Jie wrote:
On 2018年06月07日 16:06, Keyon Jie wrote:
On 2018年05月31日 19:51, Liam Girdwood wrote:
On Thu, 2018-05-31 at 16:05 +0800, Keyon Jie wrote:
The 256 Bytes block are used frequently for component new, 16 is not enough for GP-MRB multiple SSPs/pipelines support, here expand it to be 64.
Signed-off-by: Keyon Jie yang.jie@linux.intel.com
Test with: APL-MRB with tdf8532 codec Linux topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f SOF master: 48a61423f6c2d2bcf5fad854a9b3d37dfb43b546 Tool master: 7ee114d2ed822a0dbfc0dc3a37fd5c4977e00be8
src/platform/apollolake/include/platform/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/platform/apollolake/include/platform/memory.h b/src/platform/apollolake/include/platform/memory.h index e7f3ee3..652db96 100644 --- a/src/platform/apollolake/include/platform/memory.h +++ b/src/platform/apollolake/include/platform/memory.h @@ -159,7 +159,7 @@ #define HEAP_RT_COUNT32 128 #define HEAP_RT_COUNT64 64 #define HEAP_RT_COUNT128 32 -#define HEAP_RT_COUNT256 16 +#define HEAP_RT_COUNT256 64 #define HEAP_RT_COUNT512 8 #define HEAP_RT_COUNT1024 4
Can you check this does not overflow the HEAP into another section. We could also look at deprecating 1024 & 512 and giving this space up to the others.
this change will increase HEAP_RUNTIME_SIZE with 4KB, and HEAP_BUFFER_BASE will be shifted 4KB upper also, actually HEAP_BUFFER_SIZE will be decreased 4KB at the end.
Sorry, it should be (4 - 1) * 4KB = 12KB shift.
Ok, can you do likewise for the other platforms and decrease 1024 to 0 (giving it's space to 128, 64 and 32
Liam
On 2018年06月07日 22:55, Liam Girdwood wrote:
On Thu, 2018-06-07 at 16:23 +0800, Keyon Jie wrote:
On 2018年06月07日 16:06, Keyon Jie wrote:
On 2018年05月31日 19:51, Liam Girdwood wrote:
On Thu, 2018-05-31 at 16:05 +0800, Keyon Jie wrote:
The 256 Bytes block are used frequently for component new, 16 is not enough for GP-MRB multiple SSPs/pipelines support, here expand it to be 64.
Signed-off-by: Keyon Jie yang.jie@linux.intel.com
Test with: APL-MRB with tdf8532 codec Linux topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f SOF master: 48a61423f6c2d2bcf5fad854a9b3d37dfb43b546 Tool master: 7ee114d2ed822a0dbfc0dc3a37fd5c4977e00be8
src/platform/apollolake/include/platform/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/platform/apollolake/include/platform/memory.h b/src/platform/apollolake/include/platform/memory.h index e7f3ee3..652db96 100644 --- a/src/platform/apollolake/include/platform/memory.h +++ b/src/platform/apollolake/include/platform/memory.h @@ -159,7 +159,7 @@ #define HEAP_RT_COUNT32 128 #define HEAP_RT_COUNT64 64 #define HEAP_RT_COUNT128 32 -#define HEAP_RT_COUNT256 16 +#define HEAP_RT_COUNT256 64 #define HEAP_RT_COUNT512 8 #define HEAP_RT_COUNT1024 4
Can you check this does not overflow the HEAP into another section. We could also look at deprecating 1024 & 512 and giving this space up to the others.
this change will increase HEAP_RUNTIME_SIZE with 4KB, and HEAP_BUFFER_BASE will be shifted 4KB upper also, actually HEAP_BUFFER_SIZE will be decreased 4KB at the end.
Sorry, it should be (4 - 1) * 4KB = 12KB shift.
Ok, can you do likewise for the other platforms and decrease 1024 to 0 (giving it's space to 128, 64 and 32
sure, I can do that, but we have only 4KB room increase with this change and that is not enough for what COUNT256 needed. and are you sure nobody is using 1024 ones?
Thanks, ~Keyon
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
participants (3)
-
Jie, Yang -
Keyon Jie -
Liam Girdwood