Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lib: system: zephyr: Use default metal_generic_bus #287

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

glneo
Copy link
Contributor

@glneo glneo commented Mar 18, 2024

The only difference is the DMA ops, which the generic ops turns into simple cache operation which zephyr does support.

The only difference is the DMA ops, which the generic ops turns into
simple cache operation which zephyr does support.

Signed-off-by: Andrew Davis <[email protected]>
@arnopo
Copy link
Contributor

arnopo commented Apr 2, 2024

Code around metal_generic_dev_xxx is quite old and odd
As you mention map/unmap operation in zephyr is not supported. So seems better to having a structure that points to the ops. Except if you see a blocking point that would require this update...

@glneo
Copy link
Contributor Author

glneo commented Apr 2, 2024

No blocking point, this was just a general cleanup I noticed while fixing other things.

I still think this is valid though, the default handler does work for Zephyr as it just assumes a 1:1 mapping. And the default does the memory fences and cache operations one would expect. Having this set as NULL causes the functions to just return -ENODEV instead.

Zephyr could support an actual implementation of this function, but maybe a better question first, why is metal_dma_(un)map() needed at all? Baremetal and RTOS will almost never have non-1:1 memory mapping, and any caching can be done with metal_cache_*(). HLOS will not allow this from userspace. So in both cases this will always be a NOP. And I see no users of these functions, maybe time to start the process to deprecate these out?

@arnopo
Copy link
Contributor

arnopo commented Apr 5, 2024

No blocking point, this was just a general cleanup I noticed while fixing other things.

I still think this is valid though, the default handler does work for Zephyr as it just assumes a 1:1 mapping. And the default does the memory fences and cache operations one would expect. Having this set as NULL causes the functions to just return -ENODEV instead.

I think it is ok to return -ENODEV as calling in such case metal_dma_map does not make sense.

Zephyr could support an actual implementation of this function, but maybe a better question first, why is metal_dma_(un)map() needed at all? Baremetal and RTOS will almost never have non-1:1 memory mapping, and any caching can be done with metal_cache_*(). HLOS will not allow this from userspace. So in both cases this will always be a NOP. And I see no users of these functions, maybe time to start the process to deprecate these out?

The support of the Linux userspace makes the libmetal quite complexe. This is an example: the map unmap is used here https://github.com/OpenAMP/libmetal/blob/main/lib/system/linux/device.c#L537

Apply here a deprecation process seems not simple here. We would have to put a warning in the release to inform user on a risk for cachable memory.

@tnmysh @edmooring any opinion?

@tnmysh
Copy link
Collaborator

tnmysh commented May 17, 2024

No blocking point, this was just a general cleanup I noticed while fixing other things.
I still think this is valid though, the default handler does work for Zephyr as it just assumes a 1:1 mapping. And the default does the memory fences and cache operations one would expect. Having this set as NULL causes the functions to just return -ENODEV instead.

I think it is ok to return -ENODEV as calling in such case metal_dma_map does not make sense.

Zephyr could support an actual implementation of this function, but maybe a better question first, why is metal_dma_(un)map() needed at all? Baremetal and RTOS will almost never have non-1:1 memory mapping, and any caching can be done with metal_cache_*(). HLOS will not allow this from userspace. So in both cases this will always be a NOP. And I see no users of these functions, maybe time to start the process to deprecate these out?

The support of the Linux userspace makes the libmetal quite complexe. This is an example: the map unmap is used here https://github.com/OpenAMP/libmetal/blob/main/lib/system/linux/device.c#L537

Apply here a deprecation process seems not simple here. We would have to put a warning in the release to inform user on a risk for cachable memory.

@tnmysh @edmooring any opinion?

Agree with Arnaud.

@edmooring
Copy link
Contributor

No blocking point, this was just a general cleanup I noticed while fixing other things.
I still think this is valid though, the default handler does work for Zephyr as it just assumes a 1:1 mapping. And the default does the memory fences and cache operations one would expect. Having this set as NULL causes the functions to just return -ENODEV instead.

I think it is ok to return -ENODEV as calling in such case metal_dma_map does not make sense.

Zephyr could support an actual implementation of this function, but maybe a better question first, why is metal_dma_(un)map() needed at all? Baremetal and RTOS will almost never have non-1:1 memory mapping, and any caching can be done with metal_cache_*(). HLOS will not allow this from userspace. So in both cases this will always be a NOP. And I see no users of these functions, maybe time to start the process to deprecate these out?

The support of the Linux userspace makes the libmetal quite complexe. This is an example: the map unmap is used here https://github.com/OpenAMP/libmetal/blob/main/lib/system/linux/device.c#L537

Apply here a deprecation process seems not simple here. We would have to put a warning in the release to inform user on a risk for cachable memory.

@tnmysh @edmooring any opinion?

Agreed. We are between a rock and a hard place because of the demands of supporting Linux user space. It may be that the kernel's support for userspace drivers has advanced enough in the 8 years since libmetal was originally implemented that there is a simpler way now, but that is far out of the scope of what this PR is doing.

Copy link
Contributor

@edmooring edmooring left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to go.

Copy link

This pull request has been marked as a stale pull request because it has been open (more than) 45 days with no activity.

@github-actions github-actions bot added the Stale label Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants