From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752567AbcEJP5D (ORCPT ); Tue, 10 May 2016 11:57:03 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:49032 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751729AbcEJP5B (ORCPT ); Tue, 10 May 2016 11:57:01 -0400 Subject: Re: Using the mailbox subsystem for plain doorbells? To: Jassi Brar References: <5731210A.4000401@wwwdotorg.org> Cc: "linux-kernel@vger.kernel.org" , Joseph Lo From: Stephen Warren Message-ID: <573204CA.8080808@wwwdotorg.org> Date: Tue, 10 May 2016 09:56:58 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 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 05/09/2016 09:29 PM, Jassi Brar wrote: > On Tue, May 10, 2016 at 5:15 AM, Stephen Warren wrote: >> Jassi, >> >> Does the HW described below sound like something that should be represented >> using the Linux kernel's mailbox subsystem, and related DT bindings? I think >> the existing drivers/mailbox/pcc.c is similar, but wanted to double-check. >> >> We have some HW that literally just allows a SW-generated interrupt to be >> generated by our main CPU complex to an auxiliary CPU, and likewise a >> different interrupt can be generated in the opposite direction. There's no >> ability to transfer any data; just an IRQ is generated. Our current mailbox >> implementation just handles IRQ generation/reception so struct >> mbox_chan_ops.send_data completely ignores the data parameter, and our IRQ >> handler "receives" hard-coded NULL messages when the IRQ fires. Higher level >> protocol code (using shared memory along with the plain-IRQ mbox channels) >> is outside the mailbox driver. >> >> Does that fit the mailbox subsystem? >> > From the sound of it, yes. Good to know, thanks. > Some controllers need a mask/list of destination cpus, to which the > irq is raised, written to some 'data' register. You too probably need > to program the destination "id" in the controller? Maybe that should > be done in send_data(). In this case, each mailbox communicates with a different remote CPU, and there's a separate register to communicate with each remote CPU. So, send_data() completely ignores the data parameter since everything is derived from the mailbox's identity.