[alsa-devel] [PATCH] ASoC: da9055: Partially fix device

Mark Brown broonie at kernel.org
Fri Jan 17 18:20:25 CET 2014

On Thu, Jan 16, 2014 at 02:11:03AM +0000, Opensource [Adam Thomson] wrote:
> On Tue, 14 Jan 2014 19:52:19 +0000, Mark Brown wrote:

> > That's not what's been coming over.

> The drivers follow common patterns. The only thing slightly different is that
> both the Codec and PMIC are initialised separately, but this reflects the
> nature of the chip. I don't believe wanting to add a simple solution which
> fits with that as being awkward or against common methods and am not overly
> happy you're trying to suggest otherwise, especially when previous kernel
> submissions I've been involved with have very much followed common kernel
> practices. I just want the correct solution for our drivers here.

Sure, like I say this is about the impression that is created rather
than your actual intention.  One particular thing I'd highlight is that
it's really common for device vendors to say that their device or code
is special in some way and can't do the standard things but this rarely
turns out to be true.  It is therefore really important to do things
like highlight specific technical things that mean new approaches are
needed (like the fact that the addresses are independently controllable
for the functions on this device) otherwise it is very easy for it to
look like a common pattern is being repeated.

> Yes I'm sure, and there are OTP settings for the PMIC as well. For the PMIC
> address configurability, there isn't really an issue anyway as you need to
> provide the address for this I2C device at board initialisation in the kernel.
> The point of note here is that the Codec I2C address is OTP configurable and
> therefore not fixed.

OK, that's fine - I was just really surprised since the normal thing
would be that if only one function was going to have the address
configured via OTP it'd be the PMIC.

What I would suggest doing is writing a binding document for the device
(which seems to be missing anyway) and sending that along with patches
changing both the MFD and CODEC compatible strings and IDs and adding
comments saying that this is intentional to ensure that nobody cleans
this up again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140117/4e17d585/attachment.sig>

More information about the Alsa-devel mailing list