From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752633AbdGFQoz (ORCPT ); Thu, 6 Jul 2017 12:44:55 -0400 Received: from foss.arm.com ([217.140.101.70]:40124 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752566AbdGFQoy (ORCPT ); Thu, 6 Jul 2017 12:44:54 -0400 Cc: Sudeep Holla , Rob Herring , Linux Kernel Mailing List , Devicetree List , Alexey Klimov , Jassi Brar Subject: Re: [PATCH v2 2/6] Documentation: devicetree: add bindings to support ARM MHU doorbells To: Jassi Brar References: <1495621003-4291-1-git-send-email-sudeep.holla@arm.com> <1495621003-4291-3-git-send-email-sudeep.holla@arm.com> <20170531170801.u6d4fhsfu5mmqgta@rob-hp-laptop> <9a38040c-8062-870e-ab2a-beb4934428b3@arm.com> <73cf3d55-f2ec-eb15-746a-0db5e7e28dad@arm.com> <1e1fc7b3-ba5a-da30-a601-3b79122ff959@arm.com> <012a9039-23e0-be8c-add9-2c0e83a1d97e@arm.com> From: Sudeep Holla Organization: ARM Message-ID: <36ea8010-f22a-e0d9-b9a9-bb6be19db45d@arm.com> Date: Thu, 6 Jul 2017 17:44:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 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 06/07/17 15:37, Jassi Brar wrote: > On Thu, Jul 6, 2017 at 3:03 PM, Sudeep Holla wrote: [...] >> >> I said it *may not be used*, currently it is used. >> > SCPI provides more than what SCMI currently does - dvfs, clock, sensor. Not sure what you mean by that, but that's not true. > I see no reason why you must have SCPI and SCMI both running. > We can still have 2 different protocols using same MHU channel with different doorbells, what's wrong with that ? > And even then there is a solution - a shim arbitrator. Other > platforms, those share a channel, do that. No big deal. > Example please ? Please remember these protocols are generic and we can't add any platform specific code into them. > BTW, I hope you realise that we need a 'transport layer' which will > be the platform specific glue between mailbox controller specifics and > the generic SCMI code. Why ? Clearly you have not made a since technical argument so far as why MHU doorbell is not correct way even when MHU specification is clearly allows it. I have given example of ST mailbox which has this doorbell kind of support. > I see your confusion in the form of some issues in the SCMI > implementation, please CC me on the next revision. > Care to elaborate on what's my confusion or at-least what you think so ? Also if you have concern on implementation, ok we can discuss further. But can you make it clear as what your objections are for the doorbell MHU binding. How will I get the bit assigned for different protocols which are platform specific ? I still need some binding , right ? -- Regards, Sudeep