[v5,0/2] Add support for multiple coherent memory regions

Message

Howard Yen March 11, 2024, 9:49 a.m. UTC

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(-)

Comments

Andy Shevchenko March 11, 2024, 10:03 a.m. UTC | #1

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?

Howard Yen March 11, 2024, 10:10 a.m. UTC | #2

On Mon, Mar 11, 2024 at 6:03 PM Andy Shevchenko
<[e-mail]> 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
>
>

Andy Shevchenko March 11, 2024, 10:32 a.m. UTC | #3

On Mon, Mar 11, 2024 at 06:10:47PM +0800, Howard Yen wrote:
> On Mon, Mar 11, 2024 at 6:03 PM Andy Shevchenko
> <[e-mail]> 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!