From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Date: Fri, 21 Mar 2014 11:55:11 +0000 Subject: Re: [RFC PATCH] ASoC: wm8904: add CCF support Message-Id: <20140321115511.GM11706@sirena.org.uk> MIME-Version: 1 Content-Type: multipart/mixed; boundary="lzmCNsBnZbNTbhQN" List-Id: References: <1395370262-23305-1-git-send-email-voice.shen@atmel.com> <20140321103747.GK23372@e106331-lin.cambridge.arm.com> In-Reply-To: <20140321103747.GK23372@e106331-lin.cambridge.arm.com> To: Mark Rutland Cc: Bo Shen , "alsa-devel@alsa-project.org" , "b.brezillon.dev@gmail.com" , "nicolas.ferre@atmel.com" , "linux-sound@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" --lzmCNsBnZbNTbhQN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 21, 2014 at 10:37:47AM +0000, Mark Rutland wrote: > On Fri, Mar 21, 2014 at 02:51:02AM +0000, Bo Shen wrote: > > + - wlf,sysclk-from-mclk: set the sys clock is driven from mclk, > Why can the kernel not decide this? It can. > > + - wlf,mclk-use-xtal: if the mclk is generated by crystal. > > + if without this property, the mclk is generated from SOC. > Huh? What exact property do you actually are about here? This should just be omitted - based on the previous posting it's saying if this is a fixed or variable rate clock. > > + - wlf,mclk-freq: mclk's frequency > If you expect mclk, you should be able to query this from it. You don't > need a separate property. > Unless this is a frequency to set it to? If so, why can the kernel not > choose this? Yes, quite - and even if it needs to be set explicitly the clock API generic bindings should be able to support this (I *think* that is due to go in during the next merge window but iddn't check yet). --lzmCNsBnZbNTbhQN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTLCicAAoJELSic+t+oim9aXsP/3egBTy6gf1M0V2yaFuoU4Ju Cvojkz9Vp798YpKtKhbYeOvyigNVQ44AseUri7wstN41Jdll3fUEii1o+nqtpMan WGCU+I4u9WdJA6XKcQ84e+IAi4Z6uIe8CLVqiyr4wdDUQIsrJWBRsY9aKCKnueTW IAP5iwqrDNYCxm92QMv9Gi7zFtJly9aNyZwADY9WHZVYcjmU87W7n001bTtMAeje 7GK5OWVEDSqw3gpvpixy1c5qyWM57MKBvpqSo08v2EexAHahpBroeNXlLWk2lZpn jdo701oAPB6PuCOgQCOzkFjFTEk7UeTqIEGnM4NzKoDt/O865wWWZqVwXQPHYJKM urrARDuXbLHxZZ0mLWQ/EekTaTND5yeLMA4JpEsbH0WWlH+F7uNwiJD4J4RrVh7d dSc/W6J3CRTqEY8Gii2bWOsAm4+pZYECa8kGLpaVFTn/5C41aiPbMXlZAm5PW01M KAmV4HQlWk5QnMc2HsWzuiZGTS7POe7kR43kaVduKoyseuJPawXxF0jXAaAM/gSC +wcNPzbcMD1qsnDIHsbplbctZysxfIEyl8aF4RM9O39IwSotUQYJ+FJBuaogXi0/ YYTlomhilLT8agHcUe7CVokjWy80OiVSnY67vk+K5Y1zf/teJ1sKaKey2W6XKu4b KoTfs4mXHUAvNibZ/cHh =zK12 -----END PGP SIGNATURE----- --lzmCNsBnZbNTbhQN--