From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Shevchenko Subject: Re: [PATCHv7] dmaengine: Add support for BCM2835 Date: Mon, 18 Nov 2013 16:30:17 +0200 Message-ID: <1384785017.14845.214.camel@smile> References: <5288E327.8050809@koalo.de> <1384768816.14845.186.camel@smile> <528A051A.7000703@koalo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <528A051A.7000703-oZ8rN/sblLk@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Florian Meier Cc: Stephen Warren , "Koul, Vinod" , "Williams, Dan J" , Russell King - ARM Linux , devicetree , "alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org" , Liam Girdwood , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Mark Brown , linux-rpi-kernel , dmaengine , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: alsa-devel@alsa-project.org On Mon, 2013-11-18 at 13:16 +0100, Florian Meier wrote: > Thank you! Few comments below. See my answers below. > >> +static enum dma_status bcm2835_dma_tx_status(struct dma_chan *chan, > >> + dma_cookie_t cookie, struct dma_tx_state *txstate) > >> +{ > > > > [] > > > >> + } else { > >> + txstate->residue = 0; > > > > Useless assignment since dmaengine will do this for you in > > dma_cookie_status. > > I agree that it is useless, but I think otherwise it might be concealed > that there is a third case left that uses a residue of 0. Do you think a > comment is better? E.g.: > > + } else { > + /* residue = 0 per default */ I think like in many other DMA drivers either you have separate function to get residue, which returns 0, or just not include this case. > >> +static int bcm2835_dma_probe(struct platform_device *pdev) > >> +{ > >> + uint32_t chans_available; > > > > Why uint32_t? > > Because it is a bit mask of fixed length that directly comes from the > firmware. Like one already told you in your i2s patch, please, change that to corresponding u* value, namely u32. -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: andriy.shevchenko@linux.intel.com (Andy Shevchenko) Date: Mon, 18 Nov 2013 16:30:17 +0200 Subject: [PATCHv7] dmaengine: Add support for BCM2835 In-Reply-To: <528A051A.7000703@koalo.de> References: <5288E327.8050809@koalo.de> <1384768816.14845.186.camel@smile> <528A051A.7000703@koalo.de> Message-ID: <1384785017.14845.214.camel@smile> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 2013-11-18 at 13:16 +0100, Florian Meier wrote: > Thank you! Few comments below. See my answers below. > >> +static enum dma_status bcm2835_dma_tx_status(struct dma_chan *chan, > >> + dma_cookie_t cookie, struct dma_tx_state *txstate) > >> +{ > > > > [] > > > >> + } else { > >> + txstate->residue = 0; > > > > Useless assignment since dmaengine will do this for you in > > dma_cookie_status. > > I agree that it is useless, but I think otherwise it might be concealed > that there is a third case left that uses a residue of 0. Do you think a > comment is better? E.g.: > > + } else { > + /* residue = 0 per default */ I think like in many other DMA drivers either you have separate function to get residue, which returns 0, or just not include this case. > >> +static int bcm2835_dma_probe(struct platform_device *pdev) > >> +{ > >> + uint32_t chans_available; > > > > Why uint32_t? > > Because it is a bit mask of fixed length that directly comes from the > firmware. Like one already told you in your i2s patch, please, change that to corresponding u* value, namely u32. -- Andy Shevchenko Intel Finland Oy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751887Ab3KRObA (ORCPT ); Mon, 18 Nov 2013 09:31:00 -0500 Received: from mga01.intel.com ([192.55.52.88]:60885 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751236Ab3KROay (ORCPT ); Mon, 18 Nov 2013 09:30:54 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.93,724,1378882800"; d="scan'208";a="429648733" Message-ID: <1384785017.14845.214.camel@smile> Subject: Re: [PATCHv7] dmaengine: Add support for BCM2835 From: Andy Shevchenko To: Florian Meier Cc: Stephen Warren , "Koul, Vinod" , "Williams, Dan J" , Russell King - ARM Linux , devicetree , "alsa-devel@alsa-project.org" , Liam Girdwood , "linux-kernel@vger.kernel.org" , Mark Brown , linux-rpi-kernel , dmaengine , "linux-arm-kernel@lists.infradead.org" Date: Mon, 18 Nov 2013 16:30:17 +0200 In-Reply-To: <528A051A.7000703@koalo.de> References: <5288E327.8050809@koalo.de> <1384768816.14845.186.camel@smile> <528A051A.7000703@koalo.de> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2013-11-18 at 13:16 +0100, Florian Meier wrote: > Thank you! Few comments below. See my answers below. > >> +static enum dma_status bcm2835_dma_tx_status(struct dma_chan *chan, > >> + dma_cookie_t cookie, struct dma_tx_state *txstate) > >> +{ > > > > [] > > > >> + } else { > >> + txstate->residue = 0; > > > > Useless assignment since dmaengine will do this for you in > > dma_cookie_status. > > I agree that it is useless, but I think otherwise it might be concealed > that there is a third case left that uses a residue of 0. Do you think a > comment is better? E.g.: > > + } else { > + /* residue = 0 per default */ I think like in many other DMA drivers either you have separate function to get residue, which returns 0, or just not include this case. > >> +static int bcm2835_dma_probe(struct platform_device *pdev) > >> +{ > >> + uint32_t chans_available; > > > > Why uint32_t? > > Because it is a bit mask of fixed length that directly comes from the > firmware. Like one already told you in your i2s patch, please, change that to corresponding u* value, namely u32. -- Andy Shevchenko Intel Finland Oy