Support PSRAM in DmaTxBuf #2161
Conversation
liebman
force-pushed
the
dma-psram-tx-buf
branch
from
bfab3ce
to
a6f8bbd
Compare
Lovely, maybe it has something to do with the reduced bandwidth of QSPI vs OSPI? |
Actually I think it was because one of my modules only has quad psram-2m and I had it configured for opsram-2m example seems to work now |
liebman
force-pushed
the
dma-psram-tx-buf
branch
from
201a9c8
to
62f4d89
Compare
liebman
force-pushed
the
dma-psram-tx-buf
branch
from
0c8700d
to
e0600ae
Compare
liebman
force-pushed
the
dma-psram-tx-buf
branch
2 times, most recently
from
fe8ef3a
to
68f076a
Compare
liebman
force-pushed
the
dma-psram-tx-buf
branch
from
62381cf
to
0bfddcd
Compare
add `dma_tx_buffer` macro
…ed - its not needed for dram anyway.
liebman
force-pushed
the
dma-psram-tx-buf
branch
from
0bfddcd
to
37f7bff
Compare
|
?? Its 32. `DmaBufBlkSize::Size32` Where do you see 1?
…On Tue, Sep 24, 2024 at 3:06 PM Dániel Buga ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In hil-test/tests/spi_half_duplex_write_psram.rs
<#2161 (comment)>:
> + Context {
+ spi,
+ pcnt_unit: pcnt.unit0,
+ pcnt_source: mosi_loopback,
+ }
+ }
+
+ #[test]
+ #[timeout(3)]
+ fn test_spi_writes_are_correctly_by_pcnt(ctx: Context) {
+ const DMA_BUFFER_SIZE: usize = 4;
+ const DMA_ALIGNMENT: DmaBufBlkSize = DmaBufBlkSize::Size32;
+ const DMA_CHUNK_SIZE: usize = 4096 - DMA_ALIGNMENT as usize;
+
+ let (_, descriptors) = dma_descriptors_chunk_size!(0, DMA_BUFFER_SIZE, DMA_CHUNK_SIZE);
+ let buffer = dma_alloc_buffer!(DMA_BUFFER_SIZE, DMA_ALIGNMENT as usize);
Is alignment = 1 intentional here?
—
Reply to this email directly, view it on GitHub
<#2161 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANWPXEBWTLMBAL4OQEBEODZYHO6HAVCNFSM6AAAAABOIDUVYGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGMRWGU3DKNJUHE>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
I mixed up the two enums. 🤷♂️ There likely should be only one, and we should convert it differently depending on the place of use. |
| return Err(DmaBufError::UnsupportedMemoryRegion); | ||
| } | ||
| // if its PSRAM, the block_size/alignment must be specified | ||
| if is_slice_in_psram(buffer) && block_size.is_none() { |
There was a problem hiding this comment.
I don't think we do any validation here, so in theory, could we simplify all this? Could we, instead of erroring if block_size is None, assume the strictest alignment requirement, and use that for our chunk size? If yes, do we even need manually specifying block_size? The difference between 4080 and 4032 byte chunks sounds mostly negligible to me.
There was a problem hiding this comment.
I don't think we do any validation here
Isn't this the validation? Oh you mean that we don't check that the buffer aligns to the block size? That's because it's TX, fair it could be skipped.
imo the user should be able to choose and the choice should be explicit. Using bigger block sizes has bandwidth consequences for PSRAM.
Would moving the psram support to a different type get out of your way?
There was a problem hiding this comment.
Would moving the psram support to a different type get out of your way?
This isn't exactly in my way, I was just wondering. But I missed the bandwidth part of the question so I'm fine with the rest :)
Thank you for your contribution!
We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:
Submission Checklist 📝
cargo xtask fmt-packagescommand to ensure that all changed code is formatted correctly.CHANGELOG.mdin the proper section.Extra:
Pull Request Details 📖
Description
This PR adds support for PSRAM in DmaTxBuf allowing DMA transfers out from PSRAM.
Some observations:it seems to only work with octal PSRAMthere seem to be some edge cases wherechanging the CHUNK_SIZE makes it work or failchanging the BUFFER_SIZE makes it work or failTesting