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

drivers: spi: xec GPSPI driver update #59239

Closed

Conversation

Manimaran-A
Copy link
Contributor

SPI driver for Microchip XEC family General Purpose SPI (GPSPI) controller. GPSPI is a byte oriented controller with hardware support of chip select assertion. The controller and driver also supports GPIO control of SPI chip select based upon the device tree configuration. The driver supports SPI asynchronous mode for byte by byte transfers (no DMA at this time).

@zephyrbot zephyrbot added area: SPI SPI bus area: Devicetree Binding PR modifies or adds a Device Tree binding platform: Microchip MEC Microchip MEC Platform labels Jun 14, 2023
@Manimaran-A Manimaran-A force-pushed the xec_gpspi_driver branch 2 times, most recently from e62763d to 1fa5b1b Compare June 14, 2023 14:03
@Manimaran-A
Copy link
Contributor Author

@albertofloyd Could you help to review

drivers/spi/spi_xec_gpspi.c Show resolved Hide resolved
struct spi_context ctx;
struct spi_config scfg;
uint8_t configured;
uint8_t gpstatus;
Copy link
Collaborator

Choose a reason for hiding this comment

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

same here

Copy link
Contributor Author

@Manimaran-A Manimaran-A Jul 19, 2023

Choose a reason for hiding this comment

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

Re-arranged the struct members.

uint8_t gpstatus;
#ifdef CONFIG_SPI_ASYNC
uint8_t isr_ctx_done;
size_t ctx_longest_buf_len;
Copy link
Collaborator

Choose a reason for hiding this comment

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

and finally invert the order of these 2

static int xec_gpspi_spin_yield(int *counter, int max_count)
{
*counter = *counter + 1;

Copy link
Collaborator

Choose a reason for hiding this comment

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

you can remove the empty line as you are testing the same variable in the if () below

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Empty space has been removed

uint32_t lines = spi_conf->operation & SPI_LINES_MASK;

if (spi_conf->operation & (SPI_OP_MODE_SLAVE | SPI_MODE_LOOP)) {
LOG_ERR("Does not support SPI device or loop back");
Copy link
Collaborator

Choose a reason for hiding this comment

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

s/device/slave

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 the log message

uint8_t ctrl;

/* Need to reconfigure? */
ret = memcmp(&data->scfg, spi_conf, sizeof(struct spi_config));
Copy link
Collaborator

Choose a reason for hiding this comment

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

just call spi_context_configured()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Inserted the spi_context_configured api to verify already configured or not.


ctx->config = spi_conf;

memcpy(&data->scfg, spi_conf, sizeof(struct spi_config));
Copy link
Collaborator

Choose a reason for hiding this comment

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

spi_conf is not meant to change (though spi api does not strictly make it constant), since it must come from dts.
So ctx has the pointer, no need no copy the thing again.

Copy link
Contributor Author

@Manimaran-A Manimaran-A Jul 19, 2023

Choose a reason for hiding this comment

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

Here is the first place value is getting assigned to ctx->config. Device info will be read from application through DTS and passed as argument to this function. So very first we need to assign ctx->config.

cur_xfer_len = spi_context_longest_current_buf(ctx);

for (size_t i = 0; i < cur_xfer_len; i++) {

Copy link
Collaborator

Choose a reason for hiding this comment

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

remove this empty line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Space has been removed.

#ifdef CONFIG_SPI_ASYNC
/* TODO GPSPI controller is byte oriented. DMA can only be done using
* the XEC legacy DMA controller (no Zephyr driver). Therefore we
* implement asynchronous mode using GPSPI RXBF interrupt.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Looks like you are mixing up software asynchronicity and interrupt based calls.
If you controller is able to run on interrupt mode, then BOTH non-async and async calls can run on interrupt mode.

So you should not need any xec_gpspi_xfr_sync() function after all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed, but Zephyr framework has "transceive_async" and "transceive" API. In that async call, will be return immediately and after completion of transaction application call back will be invoked.

But in sync call, will be return after completion of transaction.

So "transceive" is a synchronous call, anyway we have to wait till the completion, we used polling instead of interrupt.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@tbursztyka, do you agree? or want to implement Sync call using interrupt method?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@albertofloyd could you please suggest/give direction?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@albertofloyd can you help to provide your feedback on this?

return ret;
}
#endif
ret = xec_gpspi_xfr_sync(dev, spi_conf);
Copy link
Collaborator

Choose a reason for hiding this comment

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

See above comment. Your driver does not need it as it can run on interrupt mode.
CONFIG_SPI_ASYNC is only about being able to get the cb/userdata handled relevantly, not about driver's internal logic.

@Manimaran-A Manimaran-A force-pushed the xec_gpspi_driver branch 2 times, most recently from 7f1b36f to 951ae7a Compare July 19, 2023 16:48
@Manimaran-A Manimaran-A requested a review from tbursztyka July 19, 2023 17:22
@nashif nashif assigned jvasanth1 and unassigned tbursztyka Aug 9, 2023
jvasanth1
jvasanth1 previously approved these changes Sep 19, 2023
Copy link

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

Copy link

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

@github-actions github-actions bot added the Stale label Jan 23, 2024
SPI driver for Microchip XEC family General Purpose SPI (GPSPI)
controller. GPSPI is a byte oriented controller with hardware
support of chip select assertion. The controller and driver also
supports GPIO control of SPI chip select based upon the device
tree configuration. The driver supports SPI asynchronous mode for
byte by byte transfers (no DMA at this time).

Signed-off-by: Manimaran A <manimaran.a@microchip.com>
@Manimaran-A
Copy link
Contributor Author

Planning to do a re-architecture of this driver, so closing this PR.

@Manimaran-A Manimaran-A deleted the xec_gpspi_driver branch February 23, 2024 04:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Devicetree Binding PR modifies or adds a Device Tree binding area: SPI SPI bus platform: Microchip MEC Microchip MEC Platform
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants