Re: [PATCH 2/4] dt-bindings: net: can: Make interrupt attributes optional for MCAN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux