From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail2.candelatech.com ([208.74.158.173]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1X09ER-0004tm-Fj for ath10k@lists.infradead.org; Thu, 26 Jun 2014 12:56:52 +0000 Message-ID: <53AC187C.2010309@candelatech.com> Date: Thu, 26 Jun 2014 05:56:28 -0700 From: Ben Greear MIME-Version: 1.0 Subject: Re: CT and AP firmware not allowed beaconing in adhoc mode References: <53AAC317.4050403@candelatech.com> In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Adrian Chadd , Yeoh Chun-Yeow Cc: Michal Kazior , "ath10k@lists.infradead.org" On 06/26/2014 12:43 AM, Adrian Chadd wrote: > On 26 June 2014 00:40, Yeoh Chun-Yeow wrote: >> Not possible for all the modes to be supported in one single firmware? > > It (mostly) is; it's a question of time, effort and resources. > > There's a size limitation to how much code and data you can squeeze > into the firmware. Is it possible to structure the firmware in a way > that gives you one source tree for multiple firmware builds, with > different features on and off? Quite so. > > That's just not how it happened inside of QCA. When I was working > there on the ath10k chip bringup, there indeed was one branch to do > station, adhoc and AP mode. That changed shortly after I left for > reasons I don't quite know. I'm still trying to .. well, figure out > how to try and repair that damage. In my firmware, with 37 vdevs, I have maybe 2k of RAM left, but 55+k bytes of instruction ram (ie, where the program code can live left). So, there is plenty of room for more code, and most people can get by with way less than 37 vdevs, which saves both RAM and IRAM. I am steadily improving RAM usage in CT firmware, mostly be naturally packing structures, using bit shifting instead of uint32 for booleans, etc. So, the code size is not the problem here.... Time and resources and the fact we cannot share dev efforts with other developers due to NDA issues is the main problem. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k