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

[Mark Brown]

On Thu, Jan 09, 2014 at 02:22:48PM +0000, Opensource [Adam Thomson] wrote:
> On Wed, 9 Jan 2014 12:14:53 +0000, Mark Brown wrote:

> > Hrm, you hadn't mentioned the rename in that thread.  I do note that the
> > change was from KPIT Cummins who submitted the drivers for this chip for
> > you guys and appear to be doing updates too...

> I said at the beginning of that thread that we would be taking responsibility
> of the driver and KPIT Cummins are no longer involved with this work. At that
> point the change to the PMIC I2C id name had already been made (by KPIT) and was
> in the kernel. I refer you to this mail in the thread, and to the last paragraph

Right, but at the time...

> > No, users will not have to do any extra work - if anything they have to
> > do marginally less with only registering one device.  As discussed this
> > is the way Linux handles things (which is also the rationale in the
> > changelog for the PMIC rename).  Looking at the changelogs I'd not be
> > surprised if the rename was done due to the author getting caught out by
> > the non-standard way the driver was done.

> Use JUST the codec driver. No PMIC. For some chips, 'the way Linux handles
> things' makes sense, but not here. I don't want to re-cover old ground though as
> we spent long enough over this last time.

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.

> What I would like to highlight, and it's something that concerns me more, is
> that someone went into the kernel and changed the I2C Id name for no good
> reason, and didn't test if their submission worked correctly (I am of course
> well aware in the original submission from KPIT there was a conflict in the I2C
> Id name, but that was rectified, and would've been tidied up further had it been
> permitted). On top of that you are also leaving it in an unusable state with
> your change. If we direct customers to the drivers in the mainline kernel, the
> codec cannot be simply instantiated as before, and certainly won't be
> instantiated from the MFD code. How is this acceptable?

I do agree that the current situation is not great - this is intended to
try to move things forwards since mainline is currently broken for this
device and has been for a couple of releases now.  One of the things my
patch is trying to do is to get someone to tell us what we need to plug
into i2c_add_dummy() to make this work.  I had hoped that if I wrote the
code we could get this fixed but without documentation or something that
last bit can't be done, would that be possible?
-------------- 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/20140109/59e8d089/attachment.sig>