From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D3C5EB64DC for ; Mon, 10 Jul 2023 20:00:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230059AbjGJUAU (ORCPT ); Mon, 10 Jul 2023 16:00:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55488 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230039AbjGJUAT (ORCPT ); Mon, 10 Jul 2023 16:00:19 -0400 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 408D9194 for ; Mon, 10 Jul 2023 13:00:11 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-314417861b9so4981003f8f.0 for ; Mon, 10 Jul 2023 13:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689019210; x=1691611210; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=fDVF60qAilYaG91C4u1IYCSH3KQRf6AdNGaAEoGvfFM=; b=yXU0FjwO3subDNHy0x9pE7iLeHQibHe1wXc8Q5ghRl1CKg5sYF+8CWP1pCcydOygxw h/DALfIuinvH4T5c6ROp3lh3+E775xUNKYI5sD1AKhUbD7jXWNOvDHxjfGwnr8j66uiU eyhnvt/UFOA/4zCd68xcb4smBEHSBld7lP1zTJ1Z0NZKMz4Eeq16OBlXWQlbH3DVlPyS /394p2BVbgGO8PkrPU0u/6F3P0M2YNPp+xippjq49vyUQc0Tqai+bvUC/GGVzu/EU8ku ZfqzFAO9EPvgdi/I5kYgkto1Rl5va0jLvKfu2YE1kIJgJiucrNiu2ThjInNb5t5knUHv hnAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689019210; x=1691611210; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fDVF60qAilYaG91C4u1IYCSH3KQRf6AdNGaAEoGvfFM=; b=T9Yv0UJa32Bb9xRMnCQnPKBXm+qQtF/fYMcIH/KbWUdfnyIk+g8134Yy8cwdRkx2kr 7fE8H2Tg4uUp+cyjZHr0Vz1jDeR25eLckqimApbJWo69nRkTpWy0T4Y3wwV3sERmo/CW yyJ4dof0YPc9AysbzXIS/1GvYaNqBG4p1RYf30FgZQL6lW7qnaxfJYrtX2j/YKSGh5cx kc/fh9/qRj7dqkFQSv9PfrIATZcYCk92kMlDZm+s7naTlgz/6f1aTCTZ3pVEcAR9WDDB FuMKucGsQJ3bldyLC6AkR5S+FtugzdccT2Cmq93t6IaAwdtf8fygoEzllsruVTiiqZS4 aLtw== X-Gm-Message-State: ABy/qLYEQfMFWdhSyvLx1MI1O9HvprdV8bo/WmqH4hpZzxuy5cFBa9oJ kjoFg0Fug/zQZakYmZx4xA7vrQ== X-Google-Smtp-Source: APBJJlGDvQmb2dW/BEgKveO28TYyio02FWkCpTGpsbBmFvS5kr9/mYi+3CNJaLCbTGI3oIhUgd7KNg== X-Received: by 2002:adf:dcca:0:b0:313:e953:65d0 with SMTP id x10-20020adfdcca000000b00313e95365d0mr12064440wrm.28.1689019209593; Mon, 10 Jul 2023 13:00:09 -0700 (PDT) Received: from [192.168.1.20] ([178.197.223.104]) by smtp.gmail.com with ESMTPSA id t23-20020a1709066bd700b00992025654c1sm146380ejs.179.2023.07.10.13.00.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Jul 2023 13:00:09 -0700 (PDT) Message-ID: <51a1c2e9-1165-c7ff-809d-b09e09d776e2@linaro.org> Date: Mon, 10 Jul 2023 22:00:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 1/2] dt-bindings: remoteproc: imx_rproc: Document fsl,startup-delay-ms To: Marek Vasut , linux-remoteproc@vger.kernel.org Cc: Bjorn Andersson , Conor Dooley , Fabio Estevam , Krzysztof Kozlowski , Mathieu Poirier , NXP Linux Team , Peng Fan , Pengutronix Kernel Team , Rob Herring , Sascha Hauer , Shawn Guo , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20230707232444.374431-1-marex@denx.de> <8f40484e-1721-a2bc-2344-f9e59e51a935@linaro.org> <7a1d7a67-0a0c-8527-d430-30a1cb40de48@denx.de> Content-Language: en-US From: Krzysztof Kozlowski In-Reply-To: <7a1d7a67-0a0c-8527-d430-30a1cb40de48@denx.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 10/07/2023 15:46, Marek Vasut wrote: > On 7/10/23 14:52, Krzysztof Kozlowski wrote: >> On 10/07/2023 11:18, Marek Vasut wrote: >>> On 7/10/23 10:12, Krzysztof Kozlowski wrote: >>>> On 08/07/2023 01:24, Marek Vasut wrote: >>>>> Document fsl,startup-delay-ms property which indicates how long >>>>> the system software should wait until attempting to communicate >>>>> with the CM firmware. This gives the CM firmware a bit of time >>>>> to boot and get ready for communication. >>>>> >>>>> Signed-off-by: Marek Vasut >>>>> --- >>>>> Cc: Bjorn Andersson >>>>> Cc: Conor Dooley >>>>> Cc: Fabio Estevam >>>>> Cc: Krzysztof Kozlowski >>>>> Cc: Mathieu Poirier >>>>> Cc: NXP Linux Team >>>>> Cc: Peng Fan >>>>> Cc: Pengutronix Kernel Team >>>>> Cc: Rob Herring >>>>> Cc: Sascha Hauer >>>>> Cc: Shawn Guo >>>>> Cc: devicetree@vger.kernel.org >>>>> Cc: linux-arm-kernel@lists.infradead.org >>>>> Cc: linux-remoteproc@vger.kernel.org >>>>> --- >>>>> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 5 +++++ >>>>> 1 file changed, 5 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml >>>>> index 0c3910f152d1d..c940199ce89df 100644 >>>>> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml >>>>> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml >>>>> @@ -76,6 +76,11 @@ properties: >>>>> This property is to specify the resource id of the remote processor in SoC >>>>> which supports SCFW >>>>> >>>>> + fsl,startup-delay-ms: >>>>> + default: 0 >>>>> + description: >>>>> + CM firmware start up delay. >>>> >>>> I don't see particular improvements from v2 and no responses addressing >>>> my comment: >>>> https://lore.kernel.org/all/20221102112451.128110-2-peng.fan@oss.nxp.com/ >>> >>> I wasn't aware of this being submitted before, esp. since I wrote the >>> binding document from scratch. Which comment is not addressed, the type >>> ref is not present and the sentence starts with caps, so what is missing ? >> >> >> That the property looks like a hacky solution to some SW problem. Why >> this delay should be different on different boards? > > It probably depends more on the CM4 firmware that is being launched. The > ones I tested were fine with 50..500ms delay, but the delay was always > needed. If this is for some official remoteproc FW running on M4, then probably this could be implied by compatible. Otherwise, if this depends on actual M4 firmware which can totally vary between each board of the same type (I can run my own FW on M4, right?), then it is not suitable DT property. How it would even look like? You add here 500 ms for all known firmwares and then someone comes with FW requiring delay of 600 ms. > > Sure, it is a defect of the NXP provided SDK firmware, but that may not > be fixable in all cases. Best regards, Krzysztof