[alsa-devel] [PATCH] ASoC: codecs: da9055: Update driver name to fix breakage due to pmic driver with same name

[Opensource [Adam Thomson]]

On Mon, Sep 02, 2013 at 18:14, Mark Brown wrote:

> It's always been in there, can't remember where exactly and I don't have
> access to Outlook any more.

Wish I was that lucky :-) There is an option for word wrap at a certain number
of characters but that just seems to do nothing, at least for plain text e-mails
like this. Will have to find another solution when I have some spare time.

> > The difference here is that our combined devices can also be separate chips,
> > not just one HW package containing logically separate devices. I don't believe
> > that's the case with say the TI devices.
> 
> That doesn't seem like a unique feature.

It may not be unique. To be honest I don't know. However, in terms of existing
drivers in the kernel for MFD and Codec, I don't believe there's an example
of something exactly like this in place already.

> It's the bit where the board has to register the CODEC separately at all
> that's the thing.  Think about it from the point of view of people
> writing and reviewing the machine bindings - they end up with this odd
> chip that appears twice with two names and registration schemas.

Personally I don't see the issue in having two I2C clients defined for the one
chip, in the machine bindings. Logically it's absolutely correct for the chip,
and as long as the I2C IDs for the devices make sense (which wasn't the case for
DA9055, and is something I want to rectify), then it should be obvious
to anyone who comes across that code. Actually having them as two separate
entries in machine code helps to highlight that they are individual I2C devices
in one package rather than somehow linked internally and requiring ordered
initialisation. That seems right to me, and would tally with the associated
datasheet for the device.

> > Ok, but what about the scenario where the devices start life as separate chips
> > and are then later also packaged together as one chip but still with no
> > internal connection, like DA9055. The drivers were already written and accepted
> > as separate entities in the kernel, without chained initialisation. What would
> > be the approach there? To me, logically it makes sense to leave them separate.
> 
> It doesn't seem to make much difference what order the drivers are added
> in here?  You're going to need to add a new device IDs for the SIP anyway
> since it'd presumably be badged as something new - if it wasn't then
> that's a bit different.

Yes you would add new device IDs to the drivers in question, to align with a new
device number for the combined chip, but I wouldn't expect anything more than
that as the functionality remains identical. It would simply be to document
which devices each driver supports.