Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758169Ab3D2QtL (ORCPT ); Mon, 29 Apr 2013 12:49:11 -0400 Received: from mail-oa0-f48.google.com ([209.85.219.48]:52034 "EHLO mail-oa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757127Ab3D2QtJ (ORCPT ); Mon, 29 Apr 2013 12:49:09 -0400 MIME-Version: 1.0 In-Reply-To: <517E9907.4030106@ti.com> References: <1363145021-14339-1-git-send-email-s-anna@ti.com> <37C860A02101E749A747FA2D3C1E3C504A5DF7@DLEE11.ent.ti.com> <37C860A02101E749A747FA2D3C1E3C504A63B4@DLEE11.ent.ti.com> <51779304.4040003@st.com> <517867E1.7050301@ti.com> <5179AE2F.3040403@ti.com> <517B242D.7040902@ti.com> <517E9907.4030106@ti.com> Date: Mon, 29 Apr 2013 22:19:08 +0530 Message-ID: Subject: Re: [PATCHv3 00/14] drivers: mailbox: framework creation From: Jassi Brar To: Suman Anna Cc: Loic PALLARDY , Jassi Brar , "Ohad Ben-Cohen (ohad@wizery.com)" , Stephen Rothwell , "Andy Green (andy.green@linaro.org)" , Russell King , Arnd Bergmann , Tony Lindgren , Greg Kroah-Hartman , Linus Walleij , "Rafael J. Wysocki" , Linux Kernel Mailing List , "Omar Ramirez Luna (omar.ramirez@copitl.com)" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2483 Lines: 59 Hi On 29 April 2013 21:30, Suman Anna wrote: > Hi Jassi, > > On 04/26/2013 11:51 PM, Jassi Brar wrote: >>> OK, I didn't think of a no RTR interrupt-based controller. I would thing >>> that such a controller is very rudimentary. I wonder if there are any >>> controllers like this out there. >>> >> One of my controllers is like that :) > > I hope it does have a status register atleast, and not the "neither > report nor sense RTR" type. > Actually the status is not set by the h/w, but the remote's firmware implementation makes sure it sets a marker in the status register after accepting data. So with some other firmware, we might not even have the status read facility and the client will have to solely run the TX ticker. >> If the controller h/w absolutely can not tell the remote(sender) of a >> received packet (as seems to be your case), its driver shouldn't even >> try to demux the received messages. The client driver must know which >> remotes could send it a message and how to discern them on the >> platform. Some 'server' RX client is needed here. > > No demuxing, deliver the message to the different clients. It is a > protocol agreement between the clients on what the message means. Think > of this scenario akin to shared interrupts. > Please re-read. That's what I said - No demuxing by the controller driver :) > > The notify mechanism was the top-half on the interrupt handling. The > faith part is coming from the fact that you expect all the clients to do > the equivalent of the bottom-half (which would mean some duplication in > the different clients), the OMAP scenario is such that all the different > link interrupts (both rx & tx) are mapped onto a single physical > interrupt. I think this may not be applicable to your usecase, wherein > you probably expect a response back before proceeding. > Simply put - the RX by notifier method will fail should a client is speed critical. The api might provide it optionally, but direct handover should be the default option. Btw, I did put up an almost tested version of an API implementing most of the features we agree upon http://www.spinics.net/lists/kernel/msg1523873.html http://www.spinics.net/lists/kernel/msg1523874.html cheers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/