From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754914AbbDTMVr (ORCPT ); Mon, 20 Apr 2015 08:21:47 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:36341 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754547AbbDTMVm (ORCPT ); Mon, 20 Apr 2015 08:21:42 -0400 Date: Mon, 20 Apr 2015 13:21:29 +0100 From: Mark Brown To: Kevin Cernekee Cc: Liam Girdwood , dgreid@chromium.org, Andrew Bresticker , Olof Johansson , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" Message-ID: <20150420122129.GC14892@sirena.org.uk> References: <1429134141-17924-1-git-send-email-cernekee@chromium.org> <1429134141-17924-2-git-send-email-cernekee@chromium.org> <20150418113632.GE26185@sirena.org.uk> <20150418171137.GY26185@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: X-Cookie: Everyone hates me because I'm paranoid. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 2/3] ASoC: tas571x: New driver for TI TAS571x power amplifiers X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Apr 18, 2015 at 01:07:07PM -0700, Kevin Cernekee wrote: > On Sat, Apr 18, 2015 at 10:11 AM, Mark Brown wrote: > > Someone trying to use the atmel_wm8904 driver with something other than > > a wm8904 shouldn't really be expecting a good experince... > The same check shows up in numerous other drivers, including the one > for the audio controller on my board. Sounds like either that (undisclosed) driver has a problem or you're using it inappropriately. > >> Is there a stub version that I can use instead? Nothing jumped out at > >> me when looking at the other codec drivers. > > No, such a stub would make no sense - why would we put a stub in all the > > drivers rather than just making the core do the right thing? > AFAICT, implementing the set_sysclk callback is mandatory, even if it > is a no-op on the codec side. If I delete the stub function, audio > playback fails. For the reasons I mentioned above having a set_sysclk() function is not mandatory and your driver will not be merged with a stub such as is currently present. As far as I can tell you are trying to bodge around some problem elsewhere in either the code or your usage of it. > Clearing just the LSB would accomplish the same thing, but would be > less obvious IMO. It would also require an extra read, and the code > is less concise. I don't think anyone is going to care about an extra read on system init, and in any case if the driver followed best practice and provided register defaults that read would be satisfied from cache. --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVNO9JAAoJECTWi3JdVIfQ5DMH/1pMUDSuO9yDgfeD1YsIw2u8 VBPFkawtdtNzJcwmNwQX1fl7RZFacH/2LD5oqB6u7AGUlwcX0gQI978v7KeDLxNY zAWxVZfWAnCKro0Dd2Od1OehilNto+WOW4JGOI10Cpdk/JdD40DoFVGkj93RzpD1 c1Xtmdo8He00S/7yF3kHklLc1MjAQarmzlIcGHi1X/leMt3l+fbw88Whay0oBYoF U7dxbBWOTNJSeH2/YMhpl68SlQXumB+wZfyWF/amyVNwx+D/LQVIB2bUrlKZPWfp sCCSFy0CZh0CBVpBtcjN7b4sRG24TpvaVgr6iPME4+yhxYRuM7CUgJ5qpA8NesA= =1YpN -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH 2/3] ASoC: tas571x: New driver for TI TAS571x power amplifiers Date: Mon, 20 Apr 2015 13:21:29 +0100 Message-ID: <20150420122129.GC14892@sirena.org.uk> References: <1429134141-17924-1-git-send-email-cernekee@chromium.org> <1429134141-17924-2-git-send-email-cernekee@chromium.org> <20150418113632.GE26185@sirena.org.uk> <20150418171137.GY26185@sirena.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Kevin Cernekee Cc: Liam Girdwood , dgreid-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, Andrew Bresticker , Olof Johansson , alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Apr 18, 2015 at 01:07:07PM -0700, Kevin Cernekee wrote: > On Sat, Apr 18, 2015 at 10:11 AM, Mark Brown wrote: > > Someone trying to use the atmel_wm8904 driver with something other than > > a wm8904 shouldn't really be expecting a good experince... > The same check shows up in numerous other drivers, including the one > for the audio controller on my board. Sounds like either that (undisclosed) driver has a problem or you're using it inappropriately. > >> Is there a stub version that I can use instead? Nothing jumped out at > >> me when looking at the other codec drivers. > > No, such a stub would make no sense - why would we put a stub in all the > > drivers rather than just making the core do the right thing? > AFAICT, implementing the set_sysclk callback is mandatory, even if it > is a no-op on the codec side. If I delete the stub function, audio > playback fails. For the reasons I mentioned above having a set_sysclk() function is not mandatory and your driver will not be merged with a stub such as is currently present. As far as I can tell you are trying to bodge around some problem elsewhere in either the code or your usage of it. > Clearing just the LSB would accomplish the same thing, but would be > less obvious IMO. It would also require an extra read, and the code > is less concise. I don't think anyone is going to care about an extra read on system init, and in any case if the driver followed best practice and provided register defaults that read would be satisfied from cache. --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVNO9JAAoJECTWi3JdVIfQ5DMH/1pMUDSuO9yDgfeD1YsIw2u8 VBPFkawtdtNzJcwmNwQX1fl7RZFacH/2LD5oqB6u7AGUlwcX0gQI978v7KeDLxNY zAWxVZfWAnCKro0Dd2Od1OehilNto+WOW4JGOI10Cpdk/JdD40DoFVGkj93RzpD1 c1Xtmdo8He00S/7yF3kHklLc1MjAQarmzlIcGHi1X/leMt3l+fbw88Whay0oBYoF U7dxbBWOTNJSeH2/YMhpl68SlQXumB+wZfyWF/amyVNwx+D/LQVIB2bUrlKZPWfp sCCSFy0CZh0CBVpBtcjN7b4sRG24TpvaVgr6iPME4+yhxYRuM7CUgJ5qpA8NesA= =1YpN -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- -- 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