-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Conversation
f0a129f
to
f8a6729
Compare
@@ -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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
f8a6729
to
317a33d
Compare
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. |
There was a problem hiding this 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.
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. |
I haven't yet done a full review, but I will do so once the |
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"; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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";
.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will recheck it.
There was a problem hiding this comment.
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/ec_host_cmd_backend_spi_stm32.c
Outdated
Show resolved
Hide resolved
a8a4964
to
2e536e2
Compare
subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_spi_stm32.c
Outdated
Show resolved
Hide resolved
subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_spi_stm32.c
Outdated
Show resolved
Hide resolved
subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_spi_stm32.c
Outdated
Show resolved
Hide resolved
subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_spi_stm32.c
Outdated
Show resolved
Hide resolved
ac1ae77
to
568351e
Compare
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]>
568351e
to
5884b48
Compare
@erwango do you still request any change? |
I think Erwan is off until next week. |
@erwango friendly ping :-) |
PR adds support for SPI STM32 backend.