Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp1042377ybd; Wed, 26 Jun 2019 10:10:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqwRP3xSq8hAJG2lU0BzacxC+B2rqQrGXCmS79UgToWSg6bZkz7+fShB4oJ8wEJ5/Fx3p3L8 X-Received: by 2002:a17:90a:ad89:: with SMTP id s9mr108398pjq.41.1561569004281; Wed, 26 Jun 2019 10:10:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561569004; cv=none; d=google.com; s=arc-20160816; b=GagiVukHcUVAsbMrukomTDEoQkMzlLBV4QiTDg6IC1mnAFEabjG9nQGNM3Ngz2taq1 ZnewJIUDVr/V20Plta0so8PHTMPCCmYP6I3caOqeb9gn7OwJvl/Gvh68v8vtMN5c+eHD RpxmEnn2tkzgfJJcISVAKdHdW9yNREbjafA7wRwMUj2JexJMZCnmmoi97NUnyV+Qu2EJ +G7FncuV2nE6kYFQb+W0/9ZVO1gyXtk/+TlyHE94gnRYHh3T4UPlqH4elhbwOHUXLE1v oC8pObn+PeuljADpfhYvGfQBN/EbcQyepSGwYr6NehHOECdwIndBtYC3r5TT7VI7IfjY bRBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=CKJ18rRNzuQgwyjiAK/2fjuj3KqWOJJTmMdpcmXlMg4=; b=YyubpKITQTbS5nV1k4ObcsbbUyE5tr7869Lc+XEWrFVqEQNiG1ztiXmvqIEduoCaMq p89kYUXZGDt7ab05UaYsMKqCWZwPRvdsEQZJs5bQg1ihfTfoV2r0S+TMJOwQgeZ03sIR xKdqMUysnE5RccxVb5go48s+FmXltjiHOo2oAJ8Z4/GdzfmrLXv3Pp8hq9DWX680404i C3N5ETorPm0vXP9iMqjnWPNMh1h41II/Y506DSclHwdofLdoaFaR7l/xp0z/90s6zcv2 0ZjLVoNkg6PNd9xUg3r5a4dyOxDkwFYqz9X6UxPOH2564zZlUYNrXzTdf5+Y+lRWv98J t9Pw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l1si3870700plg.398.2019.06.26.10.09.47; Wed, 26 Jun 2019 10:10:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726468AbfFZRJY (ORCPT + 99 others); Wed, 26 Jun 2019 13:09:24 -0400 Received: from foss.arm.com ([217.140.110.172]:37470 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726006AbfFZRJY (ORCPT ); Wed, 26 Jun 2019 13:09:24 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5AD402B; Wed, 26 Jun 2019 10:09:23 -0700 (PDT) Received: from e107155-lin (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6DAB53F718; Wed, 26 Jun 2019 10:09:21 -0700 (PDT) Date: Wed, 26 Jun 2019 18:09:19 +0100 From: Sudeep Holla To: Florian Fainelli Cc: Peng Fan , Jassi Brar , Rob Herring , Mark Rutland , ", Sascha Hauer" , dl-linux-imx , Shawn Guo , "festevam@gmail.com" , Devicetree List , Linux Kernel Mailing List , "linux-arm-kernel@lists.infradead.org" , Andre Przywara , "van.freenix@gmail.com" , Sudeep Holla Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox Message-ID: <20190626170919.GC13572@e107155-lin> References: <20190603083005.4304-1-peng.fan@nxp.com> <20190603083005.4304-3-peng.fan@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 26, 2019 at 09:44:06AM -0700, Florian Fainelli wrote: > On 6/26/19 6:31 AM, Peng Fan wrote: > >>> The firmware driver might not have func-id, such as SCMI/SCPI. > >>> So add an optional func-id to let smc mailbox driver could > >>> use smc SiP func id. > >>> > >> There is no end to conforming to protocols. Controller drivers should > >> be written having no particular client in mind. > > > > If the func-id needs be passed from user, then the chan_id suggested > > by Sudeep should also be passed from user, not in mailbox driver. > > > > Jassi, so from your point, arm_smc_send_data just send a0 - a6 > > to firmware, right? > > > > Sudeep, Andre, Florian, > > > > What's your suggestion? SCMI not support, do you have > > plan to add smc transport in SCMI? > > On the platforms that I work with, we have taken the liberty of > implementing SCMI in our monitor firmware because the other MCU we use > for dynamic voltage and frequency scaling did not have enough memory to > support that and we still had the ability to make that firmware be > trusted enough we could give it power management responsibilities. I > would certainly feel more comfortable if the SCMI specification was > amended to indicate that the Agent could be such a software entity, > still residing on the same host CPU as the Platform(s), but if not, > that's fine. > That's completely legal and there's nothing in the specification that prohibits. I understand it's not explicitly not mentioned and I have been trying to get such things clarified. But since it's main focus is on the message protocol, the clarity on transport mechanism is very thin and there's hesitation to add more details under the impression that it may restrict the usage. But as I mentioned, I understand what you need there :) > This has lead us to implement a mailbox driver that uses a proprietary > SMC call for the P2A path ("tx" channel) and the return being done via > either that same SMC or through SGI. You can take a look at it in our > downstream tree here actually: > > https://github.com/Broadcom/stblinux-4.9/blob/master/linux/drivers/mailbox/brcmstb-mailbox.c > Just curious, I see it's fast call and why do you still depend on interrupt to indicate completion of the message. Will the return from SMC not suffice ? Sorry if I am missing something obvious. -- Regards, Sudeep