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

On Thu, Aug 29, 2013 at 13:08, Ashish Chavan wrote:

> Apologies for my delayed response. Unfortunately I need to come out of
> this activity abruptly. One of my colleague, Adam Thomson will take this
> thread forward and will help in doing all required updates to the
> driver. He will also serve as future maintainer for DA9055 codec driver.
> 
> Thanks for all your support till date.

Hi Mark,

As Ashish mentioned, I'm now taking responsibility for this. Would be good to get
a quick resolution as this has been dragging along for some time now.

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.

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
and ownership of the Codec register map should be in the Codec driver itself and
not performed outside by other code. If you were to use the Codec driver as a
standalone device, using the above approach, you would need to write some additional
code to create the regmap structure before you could use the driver. Seems logically
wrong to me and provides an unnecessary step for anyone wanting to use the driver.

I currently see two options on how to proceed with this:

1) Simply modify the Codec driver to use a different I2C id string and leave the rest of
the functionality as is (as was previously suggested, and my preferred option).

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.

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?

  reply	other threads:[~2013-09-02  9:54 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] [this message]
2013-09-02 10:38                                   ` [alsa-devel] " Mark Brown
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=2E89032DDAA8B9408CB92943514A033751E611AF@SW-EX-MBX01.diasemi.com \
    --to=adam.thomson.opensource@diasemi.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=ashish.chavan@kpitcummins.com \
    --cc=broonie@kernel.org \
    --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.