Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5073421ybl; Tue, 14 Jan 2020 03:05:15 -0800 (PST) X-Google-Smtp-Source: APXvYqzIO/8vXzEyd05O9BaseEYF3SF3N+hiJ3ckkkRA9NMq8ikYxgDYsSaFH5/xwbl0BELlJyN1 X-Received: by 2002:aca:c30d:: with SMTP id t13mr16364496oif.166.1578999915451; Tue, 14 Jan 2020 03:05:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578999915; cv=none; d=google.com; s=arc-20160816; b=hSv2uhaXgQ21DQQlVtgUFwBgoaD+nvMmBp6KYJapnhk+gbrR3w+JRTM1jwFby7pb+C +Hd8hQojACm+XMcAk4PxhLvdYkGOYrgJzfimOBg7h/YIdRLioge4kUJXf746rYRO+J9j HzTKdaqTrAg+zzLIKazXiRajvSQaYtvfWh1L2FEH3akJHcx9eYpKj9PK5vfG2I1OC2Ub lUV/Kb08KolDFl1O6nZUlLqVl3v+skdDH2M2NU+3N1PDIevXDre+M7tvn/fCjAN/+iCT 6WYKEiJoe57AOcsLGXQ4fJxFyydz4RwXcjfotVTNYCUb4XwJkSh9p0dAyihSz7qPkt0i 0oMw== 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=HqHh/MDzEEkVIzpLlHZYNDIgKaV9yPSjn96aS2o1cqQ=; b=GQPstUpb2XZt9x9eeICS+m9L0diHhN6Lm14g+YfheOJfE+H05SKsgnJAYHdvgdTha0 WsPIsKp6WPvBuYVz8IVX4b88DdjzwV1b76BJaBYhEeAdWgC8nXqpPVkC8HHNtHFVF/JS yDX/CAH+UbVIkE8dypgPvmpwwBUFkUH5SrpPFkyREUYmKDXsdgGNx/7IBN2Y+F2VOGJc 7zysVO4AE4eH5BfSB1GBSaZimUXYxYl/aeDfdo/ly+WRdDJdW4rkX3XV2bSMowl3H1fi V4yOXdCQBKc4WmWVpuVXnEw1AtYdvPLQyvPfqrV+/G2711O+LOqv2S0FJ4RlIjZg7zDR /1AA== 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 c19si8943160otp.3.2020.01.14.03.05.03; Tue, 14 Jan 2020 03:05:15 -0800 (PST) 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 S1729076AbgANLDm (ORCPT + 99 others); Tue, 14 Jan 2020 06:03:42 -0500 Received: from foss.arm.com ([217.140.110.172]:50740 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725956AbgANLDl (ORCPT ); Tue, 14 Jan 2020 06:03:41 -0500 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 6F62A142F; Tue, 14 Jan 2020 03:03:41 -0800 (PST) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 566B33F6C4; Tue, 14 Jan 2020 03:03:40 -0800 (PST) Date: Tue, 14 Jan 2020 11:03:34 +0000 From: Sudeep Holla To: Viresh Kumar Cc: Arnd Bergmann , Jassi Brar , cristian.marussi@arm.com, peng.fan@nxp.com, "linux-kernel@vger.kernel.org" , Sudeep Holla , Linux ARM Subject: Re: [PATCH V2] firmware: arm_scmi: Make scmi core independent of transport type Message-ID: <20200114110223.GA47447@bogus> References: <3f5567ec928e20963d729350e6d674c4acb0c7a0.1578648530.git.viresh.kumar@linaro.org> <20200113064156.lt3xxpzygattz3he@vireshk-i7> <20200114092615.nvj6mkwkplub5ul7@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200114092615.nvj6mkwkplub5ul7@vireshk-i7> 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 Tue, Jan 14, 2020 at 02:56:15PM +0530, Viresh Kumar wrote: [...] > The scmi protocol requires a block of shared memory which is > represented by struct scmi_shared_mem, and payload is this memory > block itself. This block of memory is accessed throughout driver.c > file using ioread/write commands. If payload is transport specific, so > will be those accesses, isn't it ? Are you suggesting to move all this > to mailbox.c (the transport specific file) instead ? I am sorry, but I > am not able to understand how exactly you want me to reorder code here > :( > I don't have complete understanding of the requirements yet, but we may have to make scmi_shared_mem transport specific vaguely based on virtio requirements. I must have more info once I have discussion with them soon. I will reply to this thread after that. More likely by end of this week. Thanks for your patience, we are still trying to make sure we have gathered all the requirements. > @Sudeep: I had a question for you though. Looks like we are doing > ioremap() of this payload for every channel's tx/rx, why ? Why is the > same memory area mapped that way ? Can we just map the area once for > scmi block ? > Though it may be part of same block of memory on most of the platforms, it is not mandatory. It can be scattered. VirtIO based transport might have something like that. -- Regards, Sudeep