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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D712C43461 for ; Tue, 8 Sep 2020 09:16:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2F7712166E for ; Tue, 8 Sep 2020 09:16:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="htXgUbDf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F7712166E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lznjSq166G1Zjz6djJZr3xru/baA+EUl44KUhwD97S4=; b=htXgUbDfu/58gIyvCM6PdYzyz 6xGTu0x4cLuKah3ASkbqsybsnt/AwAseNGbV7fN2XfCXqqcgT0QFKpSdi9O4xlKF5YaS37/rlOWwn 5HibdjAkOr29V4ZM0fSFPoYI/H6WDRNUx9Om1iXqvq7wNrrAgtWDzOzYkjbemTBZw7tq1jhvOKwku u8Dcpuo7u0m68/GrjWgz4/U/IZfGJ88rSdoM+Taz/9CFIjeuM5wirUlCwHyC7YmPtTKKxZITnNx7n kIJepaHE2dCZTGCbNkHrEzEkTAwI73PykhA9vQG9B0YonZwJADR1uQFpoU0/8QxZmDLLOlEK5ZjS6 XCPKohmGA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFZib-0006jp-GD; Tue, 08 Sep 2020 09:15:13 +0000 Received: from mout.kundenserver.de ([217.72.192.75]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFZiY-0006id-LT for linux-arm-kernel@lists.infradead.org; Tue, 08 Sep 2020 09:15:11 +0000 Received: from mail-qv1-f46.google.com ([209.85.219.46]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MSKq6-1k8vu03DDc-00SdRx for ; Tue, 08 Sep 2020 11:15:08 +0200 Received: by mail-qv1-f46.google.com with SMTP id b13so7437414qvl.2 for ; Tue, 08 Sep 2020 02:15:07 -0700 (PDT) X-Gm-Message-State: AOAM5300rhrGlHxzPEgz38FE/bMb+czAOo37lBTjIWVT4d8GsK0P5OUw PmiTN2IZB52A77X1MqiyjXlFHghoppISSDWSeJs= X-Google-Smtp-Source: ABdhPJxiIPQ4rYzhI3bjSajviknmTbSrxISdggfeTRQMiIpfh+gJ5HSuqCYNegDej0bFDzfD2DGGUM33xRM7fZma9o0= X-Received: by 2002:a05:6214:292:: with SMTP id l18mr21604723qvv.11.1599556506523; Tue, 08 Sep 2020 02:15:06 -0700 (PDT) MIME-Version: 1.0 References: <20200604092052.GD8814@bogus> <20200605045645.GD12397@bogus> <20200605085830.GA32372@bogus> <20200610093334.yznxl2esv5ht27ns@vireshk-i7> <20200611100027.GB18781@bogus> <20200612052853.nds4iycie6ldjnnr@vireshk-i7> In-Reply-To: <20200612052853.nds4iycie6ldjnnr@vireshk-i7> From: Arnd Bergmann Date: Tue, 8 Sep 2020 11:14:50 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU To: Viresh Kumar X-Provags-ID: V03:K1:wkoj8D0iwb4K3JCUHD8K2kSqg/FbhWtoRpDNwyM4ag6AWepaP2a zYBAtr1vpL8vJbTGA1YcAIXjcmjZeXSUuB4IKy6eOw6NKHF1harESgzDT38ZdYAQ6q8fy77 wnDY5jWFqRKrZY4Q8Ju6OdBV0JscN6gWISnB0CQVkzEU5AWTjbfYSfnwDnfLnhQIU7wvNPl BB8kUbP8dDMECO+9qbQqw== X-UI-Out-Filterresults: notjunk:1;V03:K0:iA2m1vLnQBg=:sfXxPnbHBpDMKY/agtuwa0 shVCiCV+7RdNF5PXZ6bUP/zR+KU/DTmQGZVpfj0A4yGkhaHSHIJTM1xSF5P9GT4+0LpBRhwES 5ZkOX9Y2olhlX0RqYFOobNcrJCT4O76WHCmBzyYqrauDmEeOLVBdvX0ueIAu9IbP+/aPdECGU 0EHMAUojwWhOkHojPPWXVEahwrFDYUersQ119CeJn55DcC5wzmEe5pC0upm0dlSbr8kA7KaIy epGCyd9yAcOQFq82D3WnTj91nrDqB3bkNJ95oq+1P/t6vYy7SHY94eiG91Fuj0UnHHax7suvb 0Bf18RFzNYuE3yoFohMihI6g+d4PCed7ZsA1sXrgw/GS5GT54F+/8BaV8odOjAIyE4QFJmWDy c0TeK6y6zF6HHnPURsz6f+GEf+5q3NCukTJKsM9lT5EYla9jDaQQExYOeh9fQz+n/T8spjED1 TwLXqf21bxBvQn0Q9Ax6w4/T1gUQUbPHvvOy+gOgS4xKh/BglFP6b7o3VpHjZr4oj0ep+vQkV WWY7IkDyAunkW7ZVNAtVYA1DPH/O1cu9gBwFjKWyjs2eJqAGRpEX57OUa+5b3lAj+/n08sziK SxV4HFi4cSt7WJ6NGf7Dc8EXKdp/End/vpAUdnOx0c8xPbLyZllUu2q0i/VjIcbP7LY3mEdsz hEtRZ24/JBYi0DVI4OmtOm1WoDnZdgyDm9cRZdo2gQZvNCb7Vzp9APrD03BZ2MnodyI08mhnQ 1CvNBsrhriLxmUhS3+EU21wNdVxpp+ayEp460qYuit40RQAdcFtodRlrahkfFTk5F5dhply00 0aL3Hcddee09Mteh6UhXO5Gz3DMy00F5TH421KWFRkt7MsFVP+oHLQoiMleJPOaKBbR0HRn X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_051510_955366_87B4B406 X-CRM114-Status: GOOD ( 24.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rob Herring , Vincent Guittot , Devicetree List , Jassi Brar , Linux Kernel Mailing List , Bjorn Andersson , Sudeep Holla , Frank Rowand , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Picking up the old thread again after and getting pinged by multiple colleagues about it (thanks!) reading through the history. On Fri, Jun 12, 2020 at 7:29 AM Viresh Kumar wrote: > > On 11-06-20, 19:34, Jassi Brar wrote: > > In the first post in this thread, Viresh lamented that mailbox > > introduces "a few ms" delay in the scheduler path. > > Your own tests show that is certainly not the case -- average is the > > same as proposed virtual channels 50-100us, the best case is 3us vs > > 53us for virtual channels. > > Hmmm, I am not sure where is the confusion here Jassi. There are two > things which are very very different from each other. > > - Time taken by the mailbox framework (and remote for acknowledging > it) for completion of a single request, this can be 3us to 100s of > us. This is clear for everyone. THIS IS NOT THE PROBLEM. > > - Delay introduced by few of such requests on the last one, i.e. 5 > normal requests followed by an important one (like DVFS), the last > one needs to wait for the first 5 to finish first. THIS IS THE > PROBLEM. Earlier, Jassi also commented "Linux does not provide real-time guarantees", which to me is what actually causes the issue here: Linux having timeouts when communicating to the firmware means that it relies on the hardware and firmware having real-time behavior even when not providing real-time guarantees to its processes. When comparing the two usage models, it's clear that the minimum latency for a message delivery is always at least the time time to process an interrupt, plus at least one expensive MMIO read and one less expensive posted MMIO write for an Ack. If we have a doorbell plus out-of-band message, we need an extra DMA barrier and a read from coherent memory, both of which can be noticeable. As soon as messages are queued in the current model, the maximum latency increases by a potentially unbounded number of round-trips, while in the doorbell model that problem does not exist, so I agree that we need to handle both modes in the kernel deal with all existing hardware as well as firmware that requires low-latency communication. It also sounds like that debate is already settled because there are platforms using both modes, and in the kernel we usually end up supporting the platforms that our users have, whether we think it's a good idea or not. The only questions that I see in need of being answered are: 1. Should the binding use just different "#mbox-cells" values or also different "compatible" strings to tell that difference? 2. Should one driver try to handle both modes or should there be two drivers? It sounds like Jassi strongly prefers separate drivers, which would make separate compatible strings the more practical approach. While the argument can be made that a single piece of hardware should only have one DT description, the counter-argument would be that the behavior described by the DT here is made up by both the hardware and the firmware behind it, and they are in fact different. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel