soc: st: stm32n6: Add DCMIPP CSI IRQ #101131
Conversation
|
Hi @not-na, thanks for this patch. Could you give us some example why you need to get notifications of the CSI events ? |
etienne-lms
left a comment
There was a problem hiding this comment.
Could you refine the commit message?
soc: st: stm32n6: add DCMIPP CSI IRQ
-The STM32N6 devicetree is missing the CSI IRQ of the DCMIPP. Add it and pass it through to the ST HAL.
+Add DCMIPP CSI IRQ support for STM32N6.
Signed-off-by: Anton Puppe <[email protected]>
-on-behalf-of: @ZEISS [email protected]| <&rcc STM32_SRC_IC17 DCMIPP_SEL(2)>, | ||
| <&rcc STM32_CLOCK(APB5, 6)>; | ||
| interrupts = <48 0>; | ||
| interrupts = <48 0>, <47 0>; |
There was a problem hiding this comment.
If several interrupts are used, prefer using interrupt-names property to identify them.
(and use DT_DRV_IRQ_BY_NAME() in STM32_DCMIPP_INIT() and STM32_DCMIPP_CSI_IRQ_INIT())
There was a problem hiding this comment.
I did not know about interrupt-names, it seems useful here. If I change the main DCMIPP IRQ to e.g. DT_INST_IRQN_BY_NAME(inst, dcmipp), I also have to add interrupt-names to all other DTs using the DCMIPP driver, right? So that would be the STM32MP135.
Alternatively, I would just leave the main IRQ unchanged, basically assuming it's always the first. From what I can tell, the STM32 LTDC driver seems to do it like that.
There was a problem hiding this comment.
If interrupt-names is used - and it should be used here - then it must be used for all interrupts.
There was a problem hiding this comment.
I agree, including in stm32mp13.dtsi. interrupt-names property should be required in st,stm32-dcmipp.yaml.
There was a problem hiding this comment.
OK. I've added interrupt-names to stm32mp135.dtsi and made it mandatory in st,stm32-dcmipp.yaml.
@avolmat-st Getting notifications of CSI events allows more precise timing alignment to the sensor scan itself. This can be useful if you want to synchronize e.g. a flash to the camera. It could also be done based on the DCMIPP IRQ, but that has more jitter and depends on memory access speeds etc. Given that the CSI IRQ is easy enough to use, it seems like the logical choice for such tasks. Of course, you would not need this if you have access to the XVS etc. signals of the sensor, but some boards don't have that (e.g. the STM32N6570-DK does not give access to the XVS output of the camera). This would still be useful for all the other events and errors without having to poll for them though. |
e88b17a to
ac172cd
Compare
Add DCMIPP CSI IRQ support for STM32N6. Signed-off-by: Anton Puppe <[email protected]> on-behalf-of: @ZEISS [email protected]
ac172cd to
6f49b0b
Compare
|
Currently, the DCMIPP driver for the STM32N6 only implements the DCMIPP's own IRQ. However, the CSI part of the DCMIPP has its own IRQ, which may be useful in some applications.
This PR adds the CSI IRQ to the STM32N6 devicetree and routes it to the ST HAL, just like the main DCMIPP ISR. Applications and libraries can then implement the various
HAL_DCMIPP_CSI_*Callbackweak methods they are interested in.To demonstrate this, simply add something like below to the
drivers/video/capturesample to log every CSI SOF:As far as I can tell, only the N6 has the DCMIPP with CSI, so I only added the new IRQ to this SoC.
Please let me know if anything should be changed or more specific APIs for the various CSI events and errors are wanted.