Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756186Ab3DYJNS (ORCPT ); Thu, 25 Apr 2013 05:13:18 -0400 Received: from mail-ia0-f170.google.com ([209.85.210.170]:55049 "EHLO mail-ia0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753544Ab3DYJNR (ORCPT ); Thu, 25 Apr 2013 05:13:17 -0400 MIME-Version: 1.0 In-Reply-To: <1366279934-30761-14-git-send-email-lee.jones@linaro.org> References: <1366279934-30761-1-git-send-email-lee.jones@linaro.org> <1366279934-30761-14-git-send-email-lee.jones@linaro.org> Date: Thu, 25 Apr 2013 11:13:16 +0200 Message-ID: Subject: Re: [PATCH 13/32] dmaengine: ste_dma40: Calculate number of logical channels from physical ones From: Linus Walleij To: Lee Jones Cc: "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Arnd Bergmann , Linus WALLEIJ , Vinod Koul , Dan Williams , Per Forlin , Rabin Vincent 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: 1722 Lines: 45 On Thu, Apr 18, 2013 at 12:11 PM, Lee Jones wrote: > This change will cost ~25KB of memory, but it's worth the trade-off, > as it removes a great deal of overhead. It means that instead of only > allocating memory for the logical channels in use, it does so for all > available ones, which is 32 per physical channel. However, this now > means we can remove some platform data and we don't have to worry > about adding vendor specific variables to Device Tree. > > Cc: Vinod Koul > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Signed-off-by: Lee Jones (...) > static struct stedma40_platform_data dma40_plat_data = { > - .dev_len = DB8500_DMA_NR_DEV, So that was set to 64 in the platform... > - /* Count the number of logical channels in use */ > - for (i = 0; i < plat_data->dev_len; i++) > - if (plat_data->dev_rx[i] != 0) > - num_log_chans++; > - > - for (i = 0; i < plat_data->dev_len; i++) > - if (plat_data->dev_tx[i] != 0) > - num_log_chans++; And I guess this code snippet made it go down to <= 32 all the time, correct? Just want to understand it before I ACK. (The idea is sound.) I notice there is no check whatsoever of the bounds of plat_data->dev_[rx|tx] but that is a different problem I guess... Yours, Linus Walleij -- 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/