Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932304Ab1EJK1I (ORCPT ); Tue, 10 May 2011 06:27:08 -0400 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:37601 "EHLO www.etchedpixels.co.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751445Ab1EJK1G (ORCPT ); Tue, 10 May 2011 06:27:06 -0400 Date: Tue, 10 May 2011 11:27:34 +0100 From: Alan Cox To: "Subhasish Ghosh" Cc: "Wolfgang Grandegger" , "Arnd Bergmann" , , "Marc Kleine-Budde" , , , , , "open list" , "CAN NETWORK DRIVERS" , Subject: Re: [PATCH v4 1/1] can: add pruss CAN driver. Message-ID: <20110510112734.54160824@lxorguk.ukuu.org.uk> In-Reply-To: References: <1303474267-6344-1-git-send-email-subhasish@mistralsolutions.com> <201105041511.54095.arnd@arndb.de> <4DC163D7.9010309@grandegger.com> <201105041648.37199.arnd@arndb.de> <4DC17831.3070801@grandegger.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; x86_64-redhat-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII= Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1134 Lines: 25 On Tue, 10 May 2011 15:41:49 +0530 "Subhasish Ghosh" wrote: > >> > >> It sounds to me like the best solution would be change the firmware > >> to lift that restriction and simply allow all IDs, in case it's not > >> actually a hardware limitation (which sounds unlikely). > > > > Yes, that would be best but they told us, that it's not possible with > > the available hardware resources. Subhasish? > > Yes, In case if we allow the ALL implementation, it hogs the CPU. > In that case we do not need the PRU. The whole purpose of the PRU > is to offload the processor for any such implementations. So the kernel presumably needs to switch between using the PRU and native according to the number of ids being requested at the time ? That would be roughly what we do with other things (eg IP multicast) so that apps don't need to know all the innards -- 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/