On Thu, Sep 12, 2013 at 05:11:06PM +, Opensource [Adam Thomson] wrote:
> It's limiting in as much as it's insisting on a required order for
> initialisation which shouldn't be there. As said previously they're 2 separate
> devices in one package, with no internal connection, so either could
On Thu, Sep 12, 2013 at 05:11:06PM +, Opensource [Adam Thomson] wrote:
It's limiting in as much as it's insisting on a required order for
initialisation which shouldn't be there. As said previously they're 2 separate
devices in one package, with no internal connection, so either could be
On Tue, Sep 10, 2013 at 01:05:54PM +, Opensource [Adam Thomson] wrote:
> Your suggestion is to move initialisation of the Codec to the MFD core of the
> PMIC driver which to me is unnecessary and limiting and is something I cannot
> agree with. Basically we're at a bit of an impasse here...
On Tue, Sep 10, 2013 at 01:05:54PM +, Opensource [Adam Thomson] wrote:
Your suggestion is to move initialisation of the Codec to the MFD core of the
PMIC driver which to me is unnecessary and limiting and is something I cannot
agree with. Basically we're at a bit of an impasse here...
On Fri, Sep 06, 2013 at 02:17:48PM +, Opensource [Adam Thomson] wrote:
> Bringing this back to DA9055 though, the current method of initialisation, for
> PMIC and Codec, isn't complicated or confusing nor does it require a lot of
> effort. As well as this the implementation is logically
On Fri, Sep 06, 2013 at 02:17:48PM +, Opensource [Adam Thomson] wrote:
Bringing this back to DA9055 though, the current method of initialisation, for
PMIC and Codec, isn't complicated or confusing nor does it require a lot of
effort. As well as this the implementation is logically sound.
On Wed, Sep 04, 2013 at 04:13:25PM +, Opensource [Adam Thomson] wrote:
> 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
On Wed, Sep 04, 2013 at 04:13:25PM +, Opensource [Adam Thomson] wrote:
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
On Mon, Sep 02, 2013 at 03:38:18PM +, Opensource [Adam Thomson] wrote:
> On Mon, Sep 02, 2013 at 11:39, Mark Brown wrote:
> > Please fix your mailer to wrap within 80 columns, it makes your mails
> > very hard to read if you don't do this.
> Yeah, sorry for that. Having to use Outlook and of
On Mon, Sep 02, 2013 at 09:49:20AM +, 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,
On Mon, Sep 02, 2013 at 09:49:20AM +, 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
On Mon, Sep 02, 2013 at 03:38:18PM +, Opensource [Adam Thomson] wrote:
On Mon, Sep 02, 2013 at 11:39, Mark Brown wrote:
Please fix your mailer to wrap within 80 columns, it makes your mails
very hard to read if you don't do this.
Yeah, sorry for that. Having to use Outlook and of
On Mon, Aug 05, 2013 at 09:21:37PM +0530, Ashish Chavan wrote:
> On Mon, 2013-08-05 at 15:42 +0100, Mark Brown wrote:
> > No, I'm talking about the same thing I was talking about originally.
> Thanks for confirming it. From our view point, we still feel that it's
> not a good design which
On Mon, Aug 05, 2013 at 01:25:31PM +0530, Ashish Chavan wrote:
> On Mon, 2013-07-29 at 17:01 +0100, Mark Brown wrote:
> > Well, it's a very unusual hardware design choice to have multiple I2C
> > endpoints in a single physical chip.
> I hope to see more of such devices in near future.
There's
On Mon, Aug 05, 2013 at 01:25:31PM +0530, Ashish Chavan wrote:
On Mon, 2013-07-29 at 17:01 +0100, Mark Brown wrote:
Well, it's a very unusual hardware design choice to have multiple I2C
endpoints in a single physical chip.
I hope to see more of such devices in near future.
There's
On Mon, Aug 05, 2013 at 09:21:37PM +0530, Ashish Chavan wrote:
On Mon, 2013-08-05 at 15:42 +0100, Mark Brown wrote:
No, I'm talking about the same thing I was talking about originally.
Thanks for confirming it. From our view point, we still feel that it's
not a good design which requires an
On Mon, Jul 29, 2013 at 08:36:26PM +0530, Ashish Chavan wrote:
> produced as a standalone codec device soon, and we hope the driver can
> be re-used directly without changes. Is this the reason why we see only
> a handful examples of suggested implementation in kernel?
Well, it's a very unusual
On Mon, Jul 29, 2013 at 08:36:26PM +0530, Ashish Chavan wrote:
produced as a standalone codec device soon, and we hope the driver can
be re-used directly without changes. Is this the reason why we see only
a handful examples of suggested implementation in kernel?
Well, it's a very unusual
On Mon, Jul 22, 2013 at 02:13:14PM +0530, Ashish Chavan wrote:
> working on it and hope to submit updated drivers in next 5-6 weeks. In
> the meanwhile you may apply quick fix (one which I already posted), if
> you find it worth.
You would need to resend, as I indicated orginally I discarded it.
On Mon, Jul 22, 2013 at 02:13:14PM +0530, Ashish Chavan wrote:
working on it and hope to submit updated drivers in next 5-6 weeks. In
the meanwhile you may apply quick fix (one which I already posted), if
you find it worth.
You would need to resend, as I indicated orginally I discarded it.
On Thu, Jul 11, 2013 at 05:06:16PM +0530, Ashish Chavan wrote:
> accommodate this level of change. Is it possible that in first go we
> just fix the breakage due to name collision so that both drivers remain
> usable. And in second iteration, we restructure both of them as you
> suggested?
To be
On Thu, Jul 11, 2013 at 05:06:16PM +0530, Ashish Chavan wrote:
accommodate this level of change. Is it possible that in first go we
just fix the breakage due to name collision so that both drivers remain
usable. And in second iteration, we restructure both of them as you
suggested?
To be
On Mon, Jul 08, 2013 at 01:24:51PM +0530, Ashish Chavan wrote:
> On Fri, 2013-07-05 at 14:37 +0100, Mark Brown wrote:
> > Your testing seems like it's not very good then - you do undersand that
> > the problem that this is supposed to be fixing is that this is a multi
> > function device? Please
On Mon, Jul 08, 2013 at 01:24:51PM +0530, Ashish Chavan wrote:
On Fri, 2013-07-05 at 14:37 +0100, Mark Brown wrote:
Your testing seems like it's not very good then - you do undersand that
the problem that this is supposed to be fixing is that this is a multi
function device? Please look
On Fri, Jul 05, 2013 at 07:05:06PM +0530, Ashish Chavan wrote:
> On Fri, 2013-07-05 at 12:44 +0100, Mark Brown wrote:
> > > static const struct i2c_device_id da9055_i2c_id[] = {
> > > - { "da9055", 0 },
> > > + { "da9055-codec", 0 },
> > > { }
> > > };
> > I can't believe that you've tested
On Fri, Jul 05, 2013 at 05:17:42PM +0530, Ashish Chavan wrote:
> This patch updates i2c driver name and device id of da9055 codec driver.
> DA9055 is a PMIC + CODEC and currently, the corresponding PMIC driver
> also registers itself with the same name as codec, i.e. "da9055".
> Because of this
On Fri, Jul 05, 2013 at 05:17:42PM +0530, Ashish Chavan wrote:
This patch updates i2c driver name and device id of da9055 codec driver.
DA9055 is a PMIC + CODEC and currently, the corresponding PMIC driver
also registers itself with the same name as codec, i.e. da9055.
Because of this the
On Fri, Jul 05, 2013 at 07:05:06PM +0530, Ashish Chavan wrote:
On Fri, 2013-07-05 at 12:44 +0100, Mark Brown wrote:
static const struct i2c_device_id da9055_i2c_id[] = {
- { da9055, 0 },
+ { da9055-codec, 0 },
{ }
};
I can't believe that you've tested this.
Yes, I have
28 matches
Mail list logo
