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

how 4 bytes or 8 bytes padding data come? #7

Open
yilonglucky opened this issue Oct 21, 2019 · 1 comment
Open

how 4 bytes or 8 bytes padding data come? #7

yilonglucky opened this issue Oct 21, 2019 · 1 comment

Comments

@yilonglucky
Copy link

When using muti-ROI feature, or multiple buffers in the same urb, how to calculate the alignment_padding?

@katieensign
Copy link
Contributor

Sorry for the late response, I had to try to refresh my memory on this code. The driver as it's written right now doesn't support the multi-ROI case of having multiple buffers in the same urb. If segmented transfers are enabled (!sg_constraint), there is the mechanism of indicating a segment size and some padding to skip over, but that's a subtle distinction because it's splitting up one image buffer into multiple chunks. Technically you should be able to do the same thing with multi-ROI, but the code is just not written to handle two or more image separate buffers in the same urb right now. If you were to try to change it, you'd have to tweak the API to be able to have N buffers passed in, and then page lock those and configure each of them for DMA as different elements in the scatter-gather list. I believe the alignment_padding calculation should stay the same, just calculating the total transfer size for all of the buffers and adding padding to ensure it's aligned with the transfer_alignment requirement calculated in u3v_core.c.

Hope this helps,
Katie

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants