From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [213.199.154.187] ([213.199.154.187]:54448 "EHLO db8outboundpool.messaging.microsoft.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750936Ab3HSG0c (ORCPT ); Mon, 19 Aug 2013 02:26:32 -0400 Date: Mon, 19 Aug 2013 14:24:39 +0800 From: Nicolin Chen Subject: Re: [PATCH v6 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver Message-ID: <20130819062438.GB10544@MrMyself> References: <6A3DF150A5B70D4F9B66A25E3F7C888D07114BC3@039-SN2MPN1-013.039d.mgd.msft.net> <20130819030743.GA10544@MrMyself> <6A3DF150A5B70D4F9B66A25E3F7C888D07116BA7@039-SN2MPN1-013.039d.mgd.msft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D07116BA7@039-SN2MPN1-013.039d.mgd.msft.net> Sender: devicetree-owner@vger.kernel.org To: Bhushan Bharat-R65777 Cc: "broonie@kernel.org" , "lars@metafoo.de" , "p.zabel@pengutronix.de" , "s.hauer@pengutronix.de" , "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , "alsa-devel@alsa-project.org" , "swarren@wwwdotorg.org" , "festevam@gmail.com" , "timur@tabi.org" , "rob.herring@calxeda.com" , "tomasz.figa@gmail.com" , "shawn.guo@linaro.org" , "linuxppc-dev@lists.ozlabs.org" List-ID: Hi Bhushan, I'll revise some as you suggest. Just a few replies here. On Mon, Aug 19, 2013 at 12:38:11PM +0800, Bhushan Bharat-R65777 wrote: > > We here suppose the reset bit would be cleared -- "The software reset will last > > 8 cycles." from RM, so if this happened to be a failure, the whole IP module > > won't be normally working as well. > > Also add a comment describing this against why cycle = 1000 is selected. If it is done in 8 cycles, 1000-cycle will be surely a safe value for it. As long as it finished in 8 cycles, it would quit anyway. Why against? > > > > +static bool fsl_spdif_volatile_reg(struct device *dev, unsigned int reg) > > > > +{ > > > > + /* Sync all registers after reset */ > > > > > > Where us sync :) ? > > > > The "return true" would do that. For volatile registers, if no "return true" > > here, the whole regmap would use the value in cache, while for some bits > > we need to trace its true value from the physical registers not from cache. > > Where will be device registers cached? Do not we program them to be non-cacheable in core? regmap has a regcache for all the mapped registers. Set the regsiters as volatile will allow the driver to sync the regcache with physical memory each time when using regmap_read/write/update_bits(). But I think I can try to use the regcache_bypass instead. Thank you, Nicolin Chen