drivers/base/core.c | 3 ++ drivers/usb/host/xhci-plat.c | 19 +++++++- include/linux/device.h | 5 +- kernel/dma/coherent.c | 92 +++++++++++++++++++++++------------- 4 files changed, 82 insertions(+), 37 deletions(-)
In the system I'm working on, there is an always-on subsystem which includes a small size memory, and several functions need to run and occupy the memory from the small memory if they need to run on the always-on subsystem. These functions must allocate the memory from the small memory region, so that they can get benefit from the always-on subsystem. So the small memory is split for multiple functions which are satisfied with their generic use cases. But in specific use cases, like USB3 devices which support the stream trasnsfer or multiple devices connect to the host, they required more memory than their pre-allocated memory region. I tried to implement it in a generic way and propose this patch to give it the ability to get the memory from the other larger memory to solve the issue. Changelog -------------------------------------------- Changes in v5: - Fix build break. - Use of_property_count_u32_elems() instead of of_property_count_elems_of_size(). Changes in v4: - Add the driver where uses the multiple coherent memory regions. Changes in v3: - Re-org the members of struct dma_coherent_mem to avoid additional pointer arithmetics and the holes inside the structure. - Use consistent naming of return value. - Re-write the dev checking statement to be more clear. Changes in v2: - Replace the pointer(dma_mem) to a list_head(dma_mems) in the device structure and initialize the list_head in device_initialize(). - Modify the required changes in coherent.c. Howard Yen (2): dma-coherent: add support for multi coherent rmems per dev usb: host: xhci-plat: add support for multi memory regions drivers/base/core.c | 3 ++ drivers/usb/host/xhci-plat.c | 19 +++++++- include/linux/device.h | 5 +- kernel/dma/coherent.c | 92 +++++++++++++++++++++++------------- 4 files changed, 82 insertions(+), 37 deletions(-) -- 2.44.0.278.ge034bb2e1d-goog
On Mon, Mar 11, 2024 at 09:49:45AM +0000, Howard Yen wrote: > In the system I'm working on, there is an always-on subsystem which > includes a small size memory, and several functions need to run and > occupy the memory from the small memory if they need to run on the > always-on subsystem. These functions must allocate the memory from the > small memory region, so that they can get benefit from the always-on > subsystem. So the small memory is split for multiple functions which are > satisfied with their generic use cases. But in specific use cases, like > USB3 devices which support the stream trasnsfer or multiple devices > connect to the host, they required more memory than their pre-allocated > memory region. I tried to implement it in a generic way and propose this > patch to give it the ability to get the memory from the other larger > memory to solve the issue. > Changelog > -------------------------------------------- > Changes in v5: > - Fix build break. > - Use of_property_count_u32_elems() instead of > of_property_count_elems_of_size(). Have you tried to use --histogram diff algo? -- With Best Regards, Andy Shevchenko
On Mon, Mar 11, 2024 at 6:03 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Mar 11, 2024 at 09:49:45AM +0000, Howard Yen wrote: > > In the system I'm working on, there is an always-on subsystem which > > includes a small size memory, and several functions need to run and > > occupy the memory from the small memory if they need to run on the > > always-on subsystem. These functions must allocate the memory from the > > small memory region, so that they can get benefit from the always-on > > subsystem. So the small memory is split for multiple functions which are > > satisfied with their generic use cases. But in specific use cases, like > > USB3 devices which support the stream trasnsfer or multiple devices > > connect to the host, they required more memory than their pre-allocated > > memory region. I tried to implement it in a generic way and propose this > > patch to give it the ability to get the memory from the other larger > > memory to solve the issue. > > > Changelog > > -------------------------------------------- > > Changes in v5: > > - Fix build break. > > - Use of_property_count_u32_elems() instead of > > of_property_count_elems_of_size(). > > Have you tried to use --histogram diff algo? Yes, I used the below command to create the patch v5. `git format-patch --cover-letter --histogram -v5 51b70ff55` > > -- > With Best Regards, > Andy Shevchenko > > -- Best Regards, Howard
On Mon, Mar 11, 2024 at 06:10:47PM +0800, Howard Yen wrote: > On Mon, Mar 11, 2024 at 6:03 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Mar 11, 2024 at 09:49:45AM +0000, Howard Yen wrote: ... > > > Changes in v5: > > > - Fix build break. > > > - Use of_property_count_u32_elems() instead of > > > of_property_count_elems_of_size(). > > > > Have you tried to use --histogram diff algo? > > Yes, I used the below command to create the patch v5. > `git format-patch --cover-letter --histogram -v5 51b70ff55` Thank you for confirming! -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.