memcpy alignment for DEVICE_nGnRnE
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Zhou,
Quoted 3 lines · Zhou Zhu
We faced one issue using memcpy for memory type
DEVICE_nGnRnE(pgprot_noncached). If the address is not aligned, exception would happen due to the alignment of this type could not be handled by hardware.
Indeed, that's expected. This memory type is the equivalent of Strongly Ordered.
Quoted 2 lines
Is there any plan and ongoing patch to support this or we need to keep address aligned for memcpy using
pgprot_noncachedmemory in drivers?
You either change the memory type to pgprot_writecombine() or use the right API (memcpy_toio/memcpy_fromio, these could be further optimised, similar to powerpc for example, but I didn't get there yet).
Signature · 1 line
Catalin
Hi Catalin,
Quoted 8 lines · Catalin Marinas
Quoted 3 lines · Zhou Zhu
We faced one issue using memcpy for memory type
DEVICE_nGnRnE(pgprot_noncached). If the address is not aligned, exception would happen due to the alignment of this type could not be handled by hardware.Indeed, that's expected. This memory type is the equivalent of Strongly Ordered.
Quoted 6 lines
Quoted 2 lines
Is there any plan and ongoing patch to support this or we need to keep address aligned for memcpy using
pgprot_noncachedmemory in drivers?You either change the memory type to
pgprot_writecombine()or use the right API (memcpy_toio/memcpy_fromio, these could be further optimised, similar to powerpc for example, but I didn't get there yet).
How should we handle Device Memory with copy_from_user / copy_to_user? Should we follow the same scheme and create copy_from_user_io / copy_to_user_io, or rather enforce that the stock routines handle alignment?
Thanks,
Mike
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Quoted 12 lines · Michael Bohan
Quoted 11 lines · Catalin Marinas
Quoted 3 lines · Zhou Zhu
We faced one issue using memcpy for memory type
DEVICE_nGnRnE(pgprot_noncached). If the address is not aligned, exception would happen due to the alignment of this type could not be handled by hardware.Indeed, that's expected. This memory type is the equivalent of Strongly Ordered.
Quoted 2 lines
Is there any plan and ongoing patch to support this or we need to keep address aligned for memcpy using
pgprot_noncachedmemory in drivers?
Quoted 8 lines
Quoted 3 lines
You either change the memory type to
pgprot_writecombine()or use the right API (memcpy_toio/memcpy_fromio, these could be further optimised, similar to powerpc for example, but I didn't get there yet).How should we handle Device Memory with
copy_from_user/copy_to_user? Should we follow the same scheme and createcopy_from_user_io/copy_to_user_io, or rather enforce that the stock routines handle alignment?
We have generic copy_from_user_toio() and copy_to_user_fromio(). Are these what you need? As with the memcpy_(to|from)io, they can be further optimised.
Signature · 1 line
Catalin
Quoted 9 lines · Catalin Marinas
Quoted 4 lines · Michael Bohan
How should we handle Device Memory with
copy_from_user/copy_to_user? Should we follow the same scheme and createcopy_from_user_io/copy_to_user_io, or rather enforce that the stock routines handle alignment?We have generic
copy_from_user_toio()andcopy_to_user_fromio(). Are these what you need? As with the memcpy_(to|from)io, they can be further optimised.
It seems these existing routines are in sound. Were you thinking the right approach would be to move them out of sound and make them per-arch defined?
What about the other two use cases: copy_from_user_fromio and copy_to_user_toio? Are those reasonable to add? These two APIs would cover the use case I had in mind.
Then what about the strange but possible use case where both the source and destination pointers are iomem? This same question applies for memcpy_fromio / memcpy_toio as well.
The implementations of copy_from_user_toio and copy_to_user_fromio are currently doing a second copy, so that seems bad for performance. We'd probably want to improve these as well if others are in agreement.
Thanks,
Mike
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Quoted 7 lines · Michael Bohan
Quoted 6 lines · Catalin Marinas
Quoted 4 lines · Michael Bohan
How should we handle Device Memory with
copy_from_user/copy_to_user? Should we follow the same scheme and createcopy_from_user_io/copy_to_user_io, or rather enforce that the stock routines handle alignment?
Quoted 7 lines
Quoted 3 lines
We have generic
copy_from_user_toio()andcopy_to_user_fromio(). Are these what you need? As with the memcpy_(to|from)io, they can be further optimised.It seems these existing routines are in sound. Were you thinking the right approach would be to move them out of sound and make them per-arch defined?
If you have a use-case outside of the sound subsystem, they can be made more generic.
Quoted 3 lines
What about the other two use cases:
copy_from_user_fromioandcopy_to_user_toio? Are those reasonable to add? These two APIs would cover the use case I had in mind.
What's the use case for these?
Quoted 3 lines
Then what about the strange but possible use case where both the source and destination pointers are iomem? This same question applies for
memcpy_fromio/memcpy_toioas well.
You can come up with many combinations but we first need to see a real use of them, eliminate the alternatives and only then look at adding new API.
Quoted 4 lines
The implementations of
copy_from_user_toioandcopy_to_user_fromioare currently doing a second copy, so that seems bad for performance. We'd probably want to improve these as well if others are in agreement.
Yes, as I said they are not optimised (but good enough as a start).
Signature · 1 line
Catalin