[alsa-devel] [PATCH] ASoC: da9055: Partially fix device
broonie at kernel.org
Mon Jan 13 22:18:58 CET 2014
On Fri, Jan 10, 2014 at 06:32:38PM +0000, Opensource [Adam Thomson] wrote:
> On Thu, 9 Jan 2014 20:24:46 +0000, Mark Brown wrote:
> > If you want to support any additional CODEC only devices with compatible
> > register maps that exist you just need to add something like less than a
> > hundred lines of mostly boilerplate code to do so in the ASoC driver.
> > It's hard to see any difference to devices that have both I2C and SPI or
> > both PCI and platform buses here. Those devices should have separate
> > device ID entries anyway.
> The point is here is that it's unnecessary what you're suggesting. You're
> basically adding more code to instantiate the Codec from the PMIC, removing the
> valid I2C code from the Codec driver, and then if a user/customer wants to use
> the Codec standalone then they need to add that code again. Agreed that new
> device Ids should be added in the future for new standalone variants, but that
> should not mean having to add all of the I2C boilerplate code again. It think
> it makes things unnecessarily messy, on top of the additional effort required.
We also get people complaining about other stylistic things that they
get asked to fix and people going round fixing style issues - the whole
reason this broke is that people noticed and fixed the fact that the
drivers looked wrong to inspection without realising that there were
multiple drivers for the device because it's not done in the manner we
usually do this (that's definitely why the CODEC driver was changed, I
picked up on it during review on submission). It's really useful to
have things follow common patterns, it makes maintianing the system
easier and it makes factoring out shareable code easier. Things like
interfaces to the rest of the system tend to get particular focus.
Please, this isn't helping...
> Well, the truth is that there are default I2C addresses for both PMIC and Codec
> but as they are standalone devices, albeit in one package, both addresses can
> be changed. This is one more reason why I don't believe we should be taking your
> method of implementation here. If you just make sure PMIC and Codec drivers
...but on the other hand this sounds like an actual technical issue
which could be a good reason to do something different - it's a bit
surprising that it didn't come up before. What exactly is the
flexibility the devices have here? It's a pretty unusual hardware
> have unique Ids then the problem is solved. If you are worried about people
> changing this again in the future (although for the life of me I don't know
> why they would), then we can add a glaring comment to dissuade them, or point
> them at the codec driver.
That's definitely required.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the Alsa-devel