All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com>
Cc: Ashish Chavan <ashish.chavan@kpitcummins.com>, lrg <lrg@ti.com>,
	alsa-devel <alsa-devel@alsa-project.org>,
	David Dajun Chen <david.chen@diasemi.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"kiran.padwal" <kiran.padwal@kpitcummins.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: codecs: da9055: Update driver name to fix breakage due to pmic driver with same name
Date: Mon, 2 Sep 2013 11:38:43 +0100	[thread overview]
Message-ID: <20130902103843.GL3084@sirena.org.uk> (raw)
In-Reply-To: <2E89032DDAA8B9408CB92943514A033751E611AF@SW-EX-MBX01.diasemi.com>

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

On Mon, Sep 02, 2013 at 09:49:20AM +0000, Opensource [Adam Thomson] wrote:

Please fix your mailer to wrap within 80 columns, it makes your mails
very hard to read if you don't do this.

> At present I believe your suggestion is to instantiate the codec regmap in the MFD
> core for the PMIC, and then pass this in as part initialisation of the codec driver,
> from the PMIC. Please correct me if I'm wrong.

That's correct.

> If I'm correct then to me this doesn't make sense. The devices are separate,
> and have completely independent register maps. As such I believe the instantiation

They are not separate, they are soldered to the board as part of the
same package - quite a few other devices use a similar scheme and are
also handled in this fashion (the TI TWL devices are one example).

> 2) Including the above change, add some optional code to the PMIC MFD core which
> uses 'i2c_new_device()' to instantiate the codec, if it's required (I guess indicated by
> platform data to the PMIC). Means the Codec can still be used as is, but the PMIC core
> code can, if required, instantiate the codec.

This is roughly what ends up happening, you do need to instantiate
another I2C client no matter what.  The important thing here is that the
CODEC does not need to be separately registered by the user, if it
really is only the I2C client that needs creating that's probably OK so
long as the user doesn't need to worry about that implementation detail.

> I personally believe option 2 seems unnecessary and it would be simple enough
> just to instantiate the codec driver from machine code, as is done for many standalone
> codecs. Am interested though in understanding the reasoning behind your suggestion,
> for devices like this which are completely independent but can share the same HW
> package. I currently don't see a good reason to make PMIC MFD core instantiate the
> codec, for this type of scenario, but maybe you see something I don't?

The reasoning is simply that if the chip design solders a single device
to the board then the software system integration should register a
single device with the system.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-09-02 10:38 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-05 11:47 [PATCH] ASoC: codecs: da9055: Update driver name to fix breakage due to pmic driver with same name Ashish Chavan
2013-07-05 11:44 ` [alsa-devel] " Mark Brown
2013-07-05 11:44   ` Mark Brown
2013-07-05 13:35   ` Ashish Chavan
2013-07-05 13:37     ` [alsa-devel] " Mark Brown
2013-07-05 13:37       ` Mark Brown
2013-07-08  7:54       ` Ashish Chavan
2013-07-08 11:26         ` [alsa-devel] " Mark Brown
2013-07-08 11:26           ` Mark Brown
2013-07-11 11:36           ` Ashish Chavan
2013-07-17 10:36             ` [alsa-devel] " Mark Brown
2013-07-17 10:36               ` Mark Brown
2013-07-22  8:43               ` Ashish Chavan
2013-07-22 10:02                 ` [alsa-devel] " Mark Brown
2013-07-22 10:02                   ` Mark Brown
2013-07-29 15:06                   ` Ashish Chavan
2013-07-29 16:01                     ` [alsa-devel] " Mark Brown
2013-08-05  7:55                       ` Ashish Chavan
2013-08-05 14:42                         ` [alsa-devel] " Mark Brown
2013-08-05 14:42                           ` Mark Brown
2013-08-05 15:51                           ` Ashish Chavan
2013-08-05 16:23                             ` [alsa-devel] " Mark Brown
2013-08-29 12:08                               ` Ashish Chavan
2013-09-02  9:49                                 ` Opensource [Adam Thomson]
2013-09-02 10:38                                   ` Mark Brown [this message]
2013-09-02 15:38                                     ` Opensource [Adam Thomson]
2013-09-02 17:41                                       ` [alsa-devel] " Mark Brown
2013-09-02 17:41                                         ` Mark Brown
2013-09-04 16:13                                         ` Opensource [Adam Thomson]
2013-09-04 18:34                                           ` [alsa-devel] " Mark Brown
2013-09-04 18:34                                             ` Mark Brown
2013-09-06 14:17                                             ` Opensource [Adam Thomson]
2013-09-09 11:26                                               ` [alsa-devel] " Mark Brown
2013-09-09 11:26                                                 ` Mark Brown
2013-09-10 13:05                                                 ` Opensource [Adam Thomson]
2013-09-10 17:07                                                   ` [alsa-devel] " Mark Brown
2013-09-10 17:07                                                     ` Mark Brown
2013-09-12 17:11                                                     ` Opensource [Adam Thomson]
2013-09-12 21:58                                                       ` [alsa-devel] " Mark Brown
2013-09-13 15:05                                                         ` Opensource [Adam Thomson]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130902103843.GL3084@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Adam.Thomson.Opensource@diasemi.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=ashish.chavan@kpitcummins.com \
    --cc=david.chen@diasemi.com \
    --cc=kiran.padwal@kpitcummins.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.