Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c7be28da-45f0-c743-9bd9-cfac2114f167@linaro.org>
Date:   Thu, 20 Apr 2023 17:47:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [PATCH 2/4] dt-bindings: net: can: Make interrupt attributes
 optional for MCAN
Content-Language: en-US
To:     Marc Kleine-Budde <mkl@pengutronix.de>, Judith Mendez <jm@ti.com>
Cc:     Chandrasekar Ramakrishnan <rcsekar@samsung.com>,
        Wolfgang Grandegger <wg@grandegger.com>,
        "David S . Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Schuyler Patton <spatton@ti.com>, Nishanth Menon <nm@ti.com>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Tero Kristo <kristo@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Oliver Hartkopp <socketcan@hartkopp.net>,
        linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-can@vger.kernel.org,
        netdev@vger.kernel.org
References: <20230419223323.20384-1-jm@ti.com>
 <20230419223323.20384-3-jm@ti.com>
 <20230420-zoom-demystify-c31d6bf25295-mkl@pengutronix.de>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <20230420-zoom-demystify-c31d6bf25295-mkl@pengutronix.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@ti.com>
> 
> 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