On 20/04/2023 12:01, Marc Kleine-Budde wrote: > On 19.04.2023 17:33:21, Judith Mendez wrote: >> For MCAN, remove interrupt and interrupt names from the required >> section. >> >> On AM62x SoC, MCANs on MCU domain do not have hardware interrupt >> routed to A53 Linux, instead they will use software interrupt >> by hrtimer. Make interrupt attributes optional in MCAN node >> by removing from required section. >> >> Signed-off-by: Judith Mendez <jm@xxxxxx> > > This series basically adds polling support to the driver, which is > needed due to HW limitations. > > The proposed logic in the driver is to use polling if > platform_get_irq_byname() fails (due to whatever reason) use polling > with a hard-coded interval. > > In the kernel I've found the following properties that describe the > polling interval: > > bindings/input/input.yaml: > > | poll-interval: > | description: Poll interval time in milliseconds. > | $ref: /schemas/types.yaml#/definitions/uint32 > > > bindings/thermal/thermal-zones.yaml: > > | polling-delay: > | $ref: /schemas/types.yaml#/definitions/uint32 > | description: > | The maximum number of milliseconds to wait between polls when > | checking this thermal zone. Setting this to 0 disables the polling > | timers setup by the thermal framework and assumes that the thermal > | sensors in this zone support interrupts. > > bindings/regulator/dlg,da9121.yaml > > | dlg,irq-polling-delay-passive-ms: > | minimum: 1000 > | maximum: 10000 > | description: | > | Specify the polling period, measured in milliseconds, between interrupt status > | update checks. Range 1000-10000 ms. > > From my point of view the poll-interval from the input subsystem looks > good. Any objections to use it to specify the polling interval for > IRQ-less devices, too? Better to skip it, if delay can be figured out by driver based on something else (e.g. clocks). Best regards, Krzysztof
