From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932320AbbENIZd (ORCPT ); Thu, 14 May 2015 04:25:33 -0400 Received: from foss.arm.com ([217.140.101.70]:38543 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753224AbbENIZ2 (ORCPT ); Thu, 14 May 2015 04:25:28 -0400 Message-ID: <55545BF4.9090809@arm.com> Date: Thu, 14 May 2015 09:25:24 +0100 From: Sudeep Holla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jassi Brar CC: Sudeep Holla , Linux Kernel Mailing List , Liviu Dudau , Lorenzo Pieralisi , "Jon Medhurst (Tixy)" , Rob Herring , Mark Rutland , Devicetree List Subject: Re: [PATCH 1/4] mailbox: add support for System Control and Power Interface(SCPI) protocol References: <1430134846-24320-1-git-send-email-sudeep.holla@arm.com> <1430134846-24320-2-git-send-email-sudeep.holla@arm.com> <55538540.1010505@arm.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/05/15 08:30, Jassi Brar wrote: > On Thu, May 14, 2015 at 12:32 PM, Jassi Brar wrote: >> >> BTW is scpi_protocol.c meant/tested to work over arm_mhu.c? The spec >> says so but I don't see how because you pass 'struct scpi_xfer*' as >> the message whereas arm_mhu.c expects u32* >> Yes it's tested using arm_mhu.c, and I have even sent updates to the binding that's incomplete as of now and *must* be pulled into v4.1. Please make sure it gets in. Otherwise clocks are optional but the driver fails to probe without that. I was initially wondering why the MHU probe is not called. scpi_xfer has the slot as first element which will have the right doorbell bit(in this case slot#0) set always. > It seems your remote doesn't interpret the value in STAT register... > so it just works. Not exactly. If you look at Figure 2-1 in the spec, it shows how STAT (along with SET/CLEAR) is used to identify the protocol. The remote can implement multiple protocol. E.g. SCPI(on Slot#0 - main topic of this series), ACPI(PCC/CPPC say on Slot#1), ABC(on Slot#X)...etc. > However the SCPI spec recommends seeing STAT register as '31 slots' > ... maybe we should try to support that. > Correct but only Slot#0 is used for SCPI. Regards, Sudeep From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sudeep Holla Subject: Re: [PATCH 1/4] mailbox: add support for System Control and Power Interface(SCPI) protocol Date: Thu, 14 May 2015 09:25:24 +0100 Message-ID: <55545BF4.9090809@arm.com> References: <1430134846-24320-1-git-send-email-sudeep.holla@arm.com> <1430134846-24320-2-git-send-email-sudeep.holla@arm.com> <55538540.1010505@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jassi Brar Cc: Sudeep Holla , Linux Kernel Mailing List , Liviu Dudau , Lorenzo Pieralisi , "Jon Medhurst (Tixy)" , Rob Herring , Mark Rutland , Devicetree List List-Id: devicetree@vger.kernel.org On 14/05/15 08:30, Jassi Brar wrote: > On Thu, May 14, 2015 at 12:32 PM, Jassi Brar wrote: >> >> BTW is scpi_protocol.c meant/tested to work over arm_mhu.c? The spec >> says so but I don't see how because you pass 'struct scpi_xfer*' as >> the message whereas arm_mhu.c expects u32* >> Yes it's tested using arm_mhu.c, and I have even sent updates to the binding that's incomplete as of now and *must* be pulled into v4.1. Please make sure it gets in. Otherwise clocks are optional but the driver fails to probe without that. I was initially wondering why the MHU probe is not called. scpi_xfer has the slot as first element which will have the right doorbell bit(in this case slot#0) set always. > It seems your remote doesn't interpret the value in STAT register... > so it just works. Not exactly. If you look at Figure 2-1 in the spec, it shows how STAT (along with SET/CLEAR) is used to identify the protocol. The remote can implement multiple protocol. E.g. SCPI(on Slot#0 - main topic of this series), ACPI(PCC/CPPC say on Slot#1), ABC(on Slot#X)...etc. > However the SCPI spec recommends seeing STAT register as '31 slots' > ... maybe we should try to support that. > Correct but only Slot#0 is used for SCPI. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html