On Wed, 8 Sep 2010 15:11:36 +0300
Eduardo Valentin wrote:
> The background here you are probably missing is that the split between
> i2c and platform drivers. That has been done because we were thinking also
> in the situation where the si4713 i2c driver could be used without the
> platform drive
Hello,
On Wed, Sep 08, 2010 at 07:59:38AM +0200, Jarkko Nikula wrote:
> Hi
>
> On Tue, 7 Sep 2010 22:49:49 +0300
> Eduardo Valentin wrote:
>
> > Hello Jarkko,
> >
> > On Sun, Jun 13, 2010 at 08:09:28PM +0200, Jarkko Nikula wrote:
> > > Convert the driver to use regulator framework instead of s
Hi
On Tue, 7 Sep 2010 22:49:49 +0300
Eduardo Valentin wrote:
> Hello Jarkko,
>
> On Sun, Jun 13, 2010 at 08:09:28PM +0200, Jarkko Nikula wrote:
> > Convert the driver to use regulator framework instead of set_power callback.
> > This with gpio_reset platform data provide cleaner way to manage c
Hello Jarkko,
On Sun, Jun 13, 2010 at 08:09:28PM +0200, Jarkko Nikula wrote:
> Convert the driver to use regulator framework instead of set_power callback.
> This with gpio_reset platform data provide cleaner way to manage chip VIO,
> VDD and reset signal inside the driver.
>
> Signed-off-by: Jar
On Sun, 13 Jun 2010 21:09:28 +0300
Jarkko Nikula wrote:
> Convert the driver to use regulator framework instead of set_power callback.
> This with gpio_reset platform data provide cleaner way to manage chip VIO,
> VDD and reset signal inside the driver.
>
> Signed-off-by: Jarkko Nikula
> Cc: Ed
Convert the driver to use regulator framework instead of set_power callback.
This with gpio_reset platform data provide cleaner way to manage chip VIO,
VDD and reset signal inside the driver.
Signed-off-by: Jarkko Nikula
Cc: Eduardo Valentin
---
I don't have specifications for this chip so I don
