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

Renesas: Smartbond: Add SPI Non-Blocking & DMA Acceleration Support #73747

Merged

Conversation

ioannis-karachalios
Copy link
Contributor

@ioannis-karachalios ioannis-karachalios commented Jun 4, 2024

This PR requires #73822.

@ioannis-karachalios ioannis-karachalios marked this pull request as draft June 4, 2024 21:07
@zephyrbot zephyrbot added platform: Renesas SmartBond Renesas Electronics Corporation, SmartBond area: DMA Direct Memory Access area: Devicetree Binding PR modifies or adds a Device Tree binding area: SPI SPI bus labels Jun 4, 2024
@ioannis-karachalios ioannis-karachalios force-pushed the da1469x-spi-async-support branch 4 times, most recently from 03835fb to 294e3ef Compare June 4, 2024 21:47
@ioannis-karachalios ioannis-karachalios marked this pull request as ready for review June 4, 2024 21:55
@ioannis-karachalios ioannis-karachalios force-pushed the da1469x-spi-async-support branch 3 times, most recently from 89bd785 to c376944 Compare June 5, 2024 04:54
Comment on lines 152 to 153
__ASSERT(((uint32_t)data->ctx.rx_buf & 0x1) == 0, "Unaligned RX BUF");
*(uint16_t *)data->ctx.rx_buf = cfg->regs->SPI_RX_TX_REG;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could we use sys_put_le16()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Comment on lines 156 to 157
__ASSERT(((uint32_t)data->ctx.rx_buf & 0x3) == 0, "Unaligned RX BUF");
*(uint32_t *)data->ctx.rx_buf = cfg->regs->SPI_RX_TX_REG;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could we use sys_put_le32()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Comment on lines 22 to 34
tx-dma-channel:
type: int
description: |
DMA channel to be reserved for SPI TX trasmissions.
It is imperative that a TX channel be assigned
an odd number that is [1, 3, 5, 7].

rx-dma-channel:
type: int
description: |
DMA channel to be reserved for SPI RX receptions.
It is imperative that a RX channel be assigned
an even number that is [0, 2, 4, 6].
Copy link
Collaborator

Choose a reason for hiding this comment

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

DA1469x Datasheet version 3.3 mentions in section 23.3.2 Peripheral to Memory Transfer:
Map the peripheral to the selected channels pair (DMA_REQ_MUX_REG[DMAxy_SEL]).

Should we use an array property dma-channel-pair to avoid misuses (e.g. RX DMA channel 0 and TX DMA channel 3)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

DMA channels and controller should be retrieved from the dmas property as commented by @decsny.

spi_smartbond_pm_policy_state_lock_put(data);
#endif
}
spi_context_cs_control(ctx, false);
Copy link
Collaborator

Choose a reason for hiding this comment

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

we should move it before line 1042, shouldn't we?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In fact, the #CS line should be de-asserted within ISR when all transfers are exercised. I also removed the spi_context_wait_for_completion as this should return immediately when in asynchronous transfers (as we discussed the naming is a bit misleading).

It is imperative that a TX channel be assigned
an odd number that is [1, 3, 5, 7].

rx-dma-channel:
Copy link
Member

Choose a reason for hiding this comment

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

this should be coming from a dmas property, why does smartbond DMA not use #dma-cells?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right. DMA channels and controller are now retrieved via DT_INST_DMAS_CELL_BY_NAME and DT_INST_DMAS_CTLR_BY_NAME macros respectively.

@@ -168,11 +584,6 @@ static int spi_smartbond_configure(const struct spi_smartbond_cfg *cfg,
return -ENOTSUP;
}

if (spi_cfg->operation & SPI_MODE_LOOP) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why removing this? (It does not seem to belong to what is being done in this commit.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Loop operations should now be supported. Should I create a separate commit for this one?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Either another commit or describe in the commit message why it is now available.

That's actually the information I am missing. it's now supported but how? because of DMA or ?
The loop mode is a test mode where a controller can send data to itself, internally, without requiring to short physically MISO/MOSI lines.

Copy link
Contributor Author

@ioannis-karachalios ioannis-karachalios Jun 7, 2024

Choose a reason for hiding this comment

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

Updated. I was under the impression the loop mode can also reflect physical shorting of MISO/MOSI.

spi_context_buffers_setup(ctx, tx_bufs, rx_bufs, data->dfs);
spi_context_cs_control(ctx, true);

#ifndef CONFIG_SPI_SMARTBOND_DMA
Copy link
Collaborator

Choose a reason for hiding this comment

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

Are you sure you want to, at built time, enable DMA or interrupt mode as exclusive mode?

What if a controller has a DMA configuration in DTS, but another one has not?

Check how spi_ll_stm32.c does this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What if a controller has a DMA configuration in DTS, but another one has not?

Fixed, COND_CODE_1 is used to check if dmas cells are defined in DTS.

Are you sure you want to, at built time, enable DMA or interrupt mode as exclusive mode?

I get the point. Since the DMA approach is actually a blocking operation, it should be bound to the blocking API. At the same time non-blocking APIs are available using the interrupt-driven approach. Will update it and let you know once this is done.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

Copy link
Collaborator

Choose a reason for hiding this comment

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

it's not a blocking/non-blocking issue (DMA is interrupt based also), I was not clear enough describing the issue I see. It's because you may have 2 SPI controllers defined in DTS, one with DMA and the other without. The issue with your first approach was that you excluded this possibility as soon as the config option for DMA is enabled.

SPI_ASYNC it not tightened to interrupt mode actually, it's enabling part of the SPI API enabling the user to not block on the transceive call.
You can have a blocking transceive call, but still running in interrupt mode. Actually and preferably, all calls should be running under interrupt mode.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the thorough analysis provided. It's now clear to me.

@ioannis-karachalios ioannis-karachalios changed the title Renesas: Smartbond: Add SPI ASYNC Support Renesas: Smartbond: Add SPI Non-Blocking & DMA Acceleration Support Jun 7, 2024
struct spi_smartbond_data *data = dev->data;
#endif

if ((current_mode != mode) SPI_SMARTBOND_DMA_REQ_WORD_ACCESS) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
if ((current_mode != mode) SPI_SMARTBOND_DMA_REQ_WORD_ACCESS) {
if ((current_mode != mode)
#ifdef CONFIG_SPI_SMARTBOND_DMA
|| (data->dfs == 4)
#endif
) {

Copy link
Contributor Author

@ioannis-karachalios ioannis-karachalios Jun 7, 2024

Choose a reason for hiding this comment

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

Rephrased

Comment on lines 359 to 396
#ifdef CONFIG_SPI_SMARTBOND_DMA
/*
* Workaround for the controller that cannot generate DMA requests
* for 4-byte bus length or when in RX FIFO mode.
*/
if ((data->dfs == 4) || (mode == SPI_SMARTBOND_FIFO_MODE_RX_ONLY)) {
mode = SPI_SMARTBOND_FIFO_NONE;
}
#endif
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we need to update comment here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

Comment on lines 421 to 423
if (data->transfer_mode != transfer_mode_new) {
data->transfer_mode = transfer_mode_new;
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
if (data->transfer_mode != transfer_mode_new) {
data->transfer_mode = transfer_mode_new;
}
data->transfer_mode = transfer_mode_new;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

@decsny decsny removed the area: Devicetree Binding PR modifies or adds a Device Tree binding label Jun 7, 2024
@decsny decsny removed their request for review June 7, 2024 17:24
@ioannis-karachalios ioannis-karachalios force-pushed the da1469x-spi-async-support branch 5 times, most recently from 872f3d4 to b564bce Compare June 9, 2024 20:29
Comment on lines 380 to 405
cfg->regs->SPI_CTRL_REG &= ~SPI_SPI_CTRL_REG_SPI_ON_Msk;

#ifdef CONFIG_SPI_SMARTBOND_DMA
/*
* Workaround for the controller that cannot generate DMA requests
* for 4-byte bus length.
*/
if (data->dfs == 4) {
mode = SPI_SMARTBOND_FIFO_NONE;
}
#endif

cfg->regs->SPI_CTRL_REG =
((cfg->regs->SPI_CTRL_REG &= ~SPI_SPI_CTRL_REG_SPI_FIFO_MODE_Msk) |
((mode << SPI_SPI_CTRL_REG_SPI_FIFO_MODE_Pos) &
SPI_SPI_CTRL_REG_SPI_FIFO_MODE_Msk));


if (mode != SPI_SMARTBOND_FIFO_NONE) {
cfg->regs->SPI_CTRL_REG &= ~SPI_SPI_CTRL_REG_SPI_DMA_TXREQ_MODE_Msk;
} else {
cfg->regs->SPI_CTRL_REG |= SPI_SPI_CTRL_REG_SPI_DMA_TXREQ_MODE_Msk;
}

if (is_enabled) {
cfg->regs->SPI_CTRL_REG |= SPI_SPI_CTRL_REG_SPI_ON_Msk;
Copy link
Collaborator

Choose a reason for hiding this comment

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

We could avoid writing to register so many times, couldn't we?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

@ioannis-karachalios ioannis-karachalios force-pushed the da1469x-spi-async-support branch 2 times, most recently from f8c417e to f9b4466 Compare June 10, 2024 15:03
This commit should deal with adding support
for asynchronous operations. It also adds
support for DMA acceleration via a Kconfig
variable (enaled by default as DMA should
be considered scales faster than the
interrupt-driven approach).

Signed-off-by: Ioannis Karachalios <[email protected]>
@ioannis-karachalios
Copy link
Contributor Author

@tbursztyka, any other update from your side? We need this PR to be merged till this Friday.

@ioannis-karachalios ioannis-karachalios added this to the v3.7.0 milestone Jun 12, 2024
@ioannis-karachalios ioannis-karachalios dismissed tbursztyka’s stale review June 13, 2024 21:28

No response while the requests are addressed.

@ioannis-karachalios
Copy link
Contributor Author

ioannis-karachalios commented Jun 13, 2024

@tbursztyka, the SPI acceleration support is quite important for us in the upcoming LTS release and we cannot miss the deadline. Please feel free to open an issue ticket if more work should be done and it will be addressed as bug during the RC2 phase. Sorry for the inconvenience and thanks for your understanding.

@nashif nashif merged commit 774ed60 into zephyrproject-rtos:main Jun 14, 2024
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: DMA Direct Memory Access area: SPI SPI bus platform: Renesas SmartBond Renesas Electronics Corporation, SmartBond
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants