From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754151AbdKBLtW (ORCPT ); Thu, 2 Nov 2017 07:49:22 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:58642 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751401AbdKBLtV (ORCPT ); Thu, 2 Nov 2017 07:49:21 -0400 Cc: Sudeep Holla , Linux Kernel Mailing List , "linux-arm-kernel@lists.infradead.org" , Arnd Bergmann , Bjorn Andersson Subject: Re: [PATCH] mailbox: add support for doorbell/signal mode controllers To: Jassi Brar References: <1509553964-4451-1-git-send-email-sudeep.holla@arm.com> <59a05fcb-ff30-0683-144e-93521a7413f9@arm.com> <4268c9d9-dc1e-0bd7-3fac-790c2d42b54b@arm.com> From: Sudeep Holla Organization: ARM Message-ID: <5af1c28f-50db-9f5a-2c60-71cacab4a3ab@arm.com> Date: Thu, 2 Nov 2017 11:49:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/11/17 11:26, Jassi Brar wrote: > On Thu, Nov 2, 2017 at 4:17 PM, Sudeep Holla wrote: [...] >> >> No that non-zero value is not client specific, it's entirely controller >> specific. >> > ?? > For example BCM2835 has such a controller. Have a look at > bcm2835_send_data() and let me know what is that controller specific > value. > You can keep finding one or the other platform that has a deviation. Come on there are generic infrastructure support in many subsystem that are just used in one or two platforms. I hope you agree for this enhancement to the mailbox framework as it's more commonly used mode. I am not saying this patch is final, but I just want an agreement to add such a support. [...] >>> 1) Where does the "whatever_value_to_trigger_signal" come from? >> >> Controller specific. >> >>> That has to come from client. >> >> No. >> > Again, let me know what does the controller expect 'val' to be > > writel(val, MAILBOX_A2B_CMD(chans->idx)) > It depends on the controller. Whatever value that can generate a signal to remote. > > Your entire post is based on your assertion that the controller > expects a particular non-zero value to trigger a signal, which is > wrong. Why do you think that ? There are lots of example in the mailbox today. Please have a look at few example which don't use data passed from the client: 1. pcc_send_data (drivers/mailbox/pcc.c) 2. sti_mbox_send_data (drivers/mailbox/mailbox-sti.c) 3. qcom_apcs_ipc_send_data (drivers/mailbox/qcom-apcs-ipc-mailbox.c) 4. tegra_hsp_doorbell_send_data (drivers/mailbox/tegra-hsp.c) And SCMI fits the above case. Also you keep saying I am making this change to get SCMI with ARM MHU. Honestly I don't care much about that, I need better support from mailbox framework if possible for any platforms running SCMI. So please stop assuming my changes are motivated by that. SCMI is designed to solve more generic consolidation issues, so I am more focused on that than getting it run on some development platform I have with ARM MHU. Believe me that's least of my concern. -- Regards, Sudeep