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

mgmt: ec_host_cmd: add spi STM32 backend #57287

Merged
merged 1 commit into from
Aug 21, 2023

Conversation

niedzwiecki-dawid
Copy link
Member

@niedzwiecki-dawid niedzwiecki-dawid commented Apr 26, 2023

PR adds support for SPI STM32 backend.

include/zephyr/mgmt/ec_host_cmd/ec_host_cmd.h Outdated Show resolved Hide resolved
subsys/mgmt/ec_host_cmd/Kconfig Outdated Show resolved Hide resolved
subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c Outdated Show resolved Hide resolved
subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c Outdated Show resolved Hide resolved
@@ -36,13 +36,43 @@ one backend layer.
.. image:: ec_host_cmd_shi.png
:align: center

Another case is SPI. Unfortunately, the current SPI API can't be used to handle the host commands
Copy link
Collaborator

Choose a reason for hiding this comment

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

@tbursztyka this seems like a problem which is causing big duplication, are there plans to address this?

Copy link
Member Author

Choose a reason for hiding this comment

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

We are discussing the problem here

@niedzwiecki-dawid
Copy link
Member Author

My plan is to add working implementation (SPI backend including driver) as a reference. In the long term, I would like to try extend the SPI API to handle host command communication flow. However, it won't be easy and requires changing/extending SPI drivers.

Copy link
Member

@fabiobaltieri fabiobaltieri left a comment

Choose a reason for hiding this comment

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

Hey how about splitting this in two PRs, one for the first three patches and a dedicated one for the SPI backend? If you expect the backend conversation to drag a long, it may make things a bit easier.

subsys/mgmt/ec_host_cmd/Kconfig Outdated Show resolved Hide resolved
subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c Outdated Show resolved Hide resolved
subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c Outdated Show resolved Hide resolved
@niedzwiecki-dawid
Copy link
Member Author

niedzwiecki-dawid commented May 12, 2023

Hey how about splitting this in two PRs, one for the first three patches and a dedicated one for the SPI backend? If you expect the backend conversation to drag a long, it may make things a bit easier.

Makes sense :-)

The PR with HC improvements. I don't know if the split can be done better.

I will rebase the SPI support once the improvement are merged.

Let continue review of the SPI STM32 backend here.

@keith-zephyr
Copy link
Contributor

I haven't yet done a full review, but I will do so once the status = "disabled" vs. updating the compatible property issue is resolved.

@niedzwiecki-dawid
Copy link
Member Author

I haven't yet done a full review, but I will do so once the status = "disabled" vs. updating the compatible property issue is resolved.

Thanks a lot for this suggestion. I'm really open to another ones to make this code less dirty.

/* Change the compatible string to use the Host Command version of the
* STM32 SPI driver
*/
compatible = "st,stm32-spi-host-cmd";
Copy link
Member

Choose a reason for hiding this comment

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

I'd suggest to handle this slightly differently and use:

			compatible = "st,stm32h7-spi", "st,stm32-spi-fifo", "st,stm32-spi-host-cmd";

This way, you keep the benefit of using "st,stm32h7-spi" and "st,stm32-spi-fifo" which are currently used to specify variants of STM32 SPI HW block.

I acknowledge this is less easy to use, but this will ease the implementation of this driver on multiple STM32 targets.
You can think or other ways to do it of course, but I think it would be easier for maintenance if you stay in sync with "main" STM32 SPI driver on that regard.

Copy link
Member Author

Choose a reason for hiding this comment

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

Please tell me if I understand it correctly.

The "st,stm32-spi" compatible string is always use for STM32 SPI block. The "st,stm32h7-spi" can be added as a second compatible string to specify variant of the SPI block that works a bit differently. "st,stm32-spi-fifo" is the same case.

So, in this case it is better just to change the "st,stm32-spi" string to "st,stm32-spi-host-cmd" and use the "additional" ones ("st,stm32h7-spi" and `"st,stm32-spi-fifo") as usual, because it doesn't cause building the standard driver anyway.

Is that correct? Thanks in advice.

Copy link
Member

Choose a reason for hiding this comment

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

This is fully correct

Fyi, spi_ll_stm32.c file is built in based on CONFIG_SPI_STM32=y, which is selected based on st,stm32-spi compat being enabled:

menuconfig SPI_STM32
	bool "STM32 MCU SPI controller driver"
	default y
	depends on DT_HAS_ST_STM32_SPI_ENABLED

Copy link
Member Author

Choose a reason for hiding this comment

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

Great, working on the change.

Copy link
Member Author

Choose a reason for hiding this comment

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

The example in the docs is still correct, right?

Copy link
Member

Choose a reason for hiding this comment

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

I don't think this file is required anymore

Copy link
Member Author

Choose a reason for hiding this comment

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

Needed devicetree macros e.g. DT_N_S_soc_S_spi_40013000_P_pinctrl_0_FOREACH_PROP_ELEM are not generated without this file for compatible = "st,stm32-spi-host-cmd";.

Copy link
Member

Choose a reason for hiding this comment

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

Sounds weird, there's likely an error somewhere

Copy link
Member Author

Choose a reason for hiding this comment

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

I will recheck it.

Copy link
Member Author

@niedzwiecki-dawid niedzwiecki-dawid May 25, 2023

Choose a reason for hiding this comment

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

I've checked it in the devicetree python scripts. It looks like the property defines e.g. DT_N_S_soc_S_spi_40013000_P_pinctrl_0_IDX_0 are not generated for nodes that does't match any binding file. I think the reason is simple - the script doesn't know the property type. Only defines for default properties(status, compatible, reg and interrupts) are generated. So in my opinion, the binding file is required here.

subsys/mgmt/ec_host_cmd/backends/Kconfig Outdated Show resolved Hide resolved
@erwango erwango self-requested a review May 25, 2023 15:32
fabiobaltieri
fabiobaltieri previously approved these changes Jun 12, 2023
@de-nordic de-nordic removed their request for review June 21, 2023 11:14
doc/services/device_mgmt/ec_host_cmd.rst Outdated Show resolved Hide resolved
doc/services/device_mgmt/ec_host_cmd.rst Outdated Show resolved Hide resolved
doc/services/device_mgmt/ec_host_cmd.rst Show resolved Hide resolved
Add support for SPI host command backend for STM32 chips family.

Unfortunately, the current SPI API can't be used to handle the host
commands communication. The main issues are unknown command size sent
by the host(the SPI transaction sends/receives specific number of bytes)
and need to constant sending status byte(the SPI module is enabled and
disabled per transaction). Thus the SPI backend includes basic SPI STM32
driver adjusted to host command specification.

Signed-off-by: Dawid Niedzwiecki <[email protected]>
@niedzwiecki-dawid
Copy link
Member Author

@erwango do you still request any change?

@fabiobaltieri
Copy link
Member

@erwango do you still request any change?

I think Erwan is off until next week.

@niedzwiecki-dawid
Copy link
Member Author

@erwango friendly ping :-)

@carlescufi carlescufi merged commit 63af3c0 into zephyrproject-rtos:main Aug 21, 2023
44 checks passed
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: ec_host_cmd area: mcumgr area: SPI SPI bus platform: STM32 ST Micro STM32
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants