On Sat, Apr 18, 2015 at 01:07:07PM -0700, Kevin Cernekee wrote: > On Sat, Apr 18, 2015 at 10:11 AM, Mark Brown <broonie@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: Digital signature
