ments Incorporated
PSP Products RSS Feed
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Friday, April 24, 2009 12:03 PM
> To: Trilok Soni
> Cc: Aggarwal, Anuj; Mark Brown; linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: Problems w
On Thursday 23 April 2009, Trilok Soni wrote:
> Thanks but I was requesting tps 6 5 0 2 3 not tps 6 2 3 5 x :).
Sorry ... maybe they'll help some other time. :)
I was wondering what happened to the tps6235x drivers,
which seemed to have gotten lost. I don't recall having
seen tps65023 code.
> -Original Message-
> From: Trilok Soni [mailto:soni.tri...@gmail.com]
> Sent: Friday, April 24, 2009 11:32 AM
> To: David Brownell
> Cc: Aggarwal, Anuj; Mark Brown; linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: Problems while designing TPS65023 regulator driver
>
Hi David,
On Fri, Apr 24, 2009 at 3:47 AM, David Brownell wrote:
> On Thursday 23 April 2009, Trilok Soni wrote:
>> Any updates on tps65023 regulator driver? Could you please submit the
>> WIP patches to the list?
>
> FWIW, here's the last version I saw ... it includes a
> build hack for the regu
On Thursday 23 April 2009, Trilok Soni wrote:
> Any updates on tps65023 regulator driver? Could you please submit the
> WIP patches to the list?
FWIW, here's the last version I saw ... it includes a
build hack for the regulator_register() call. I haven't
build-tested it since that API change went
Hi Anuj,
On Sat, Apr 4, 2009 at 5:35 AM, Tony Lindgren wrote:
> * Mark Brown [090403 01:53]:
>> On Fri, Apr 03, 2009 at 01:33:58PM +0530, Aggarwal, Anuj wrote:
>>
>> > I could not find the commit in linux-OMAP git where the init data is
>> > passed as a parameter to the regulator_register(). I a
* Mark Brown [090403 01:53]:
> On Fri, Apr 03, 2009 at 01:33:58PM +0530, Aggarwal, Anuj wrote:
>
> > I could not find the commit in linux-OMAP git where the init data is
> > passed as a parameter to the regulator_register(). I am dependent
> > on this commit for my TPS65023 regulator driver and
On Fri, Apr 03, 2009 at 01:33:58PM +0530, Aggarwal, Anuj wrote:
> I could not find the commit in linux-OMAP git where the init data is
> passed as a parameter to the regulator_register(). I am dependent
> on this commit for my TPS65023 regulator driver and could not push
> my patch without the
> Sent: Thursday, February 26, 2009 7:35 PM
> To: Aggarwal, Anuj
> Cc: linux-omap@vger.kernel.org
> Subject: Re: Problems while designing TPS65023 regulator driver
>
> On Thu, Feb 26, 2009 at 02:41:54PM +0530, Aggarwal, Anuj wrote:
>
> > Since all the five regulators can
On Mon, Mar 09, 2009 at 04:45:26PM -0800, David Brownell wrote:
> On Sunday 08 March 2009, Mark Brown wrote:
> > > - Regulators not marked as "boot_on" or "always_on" won't
> > >be active (and usecount will be 0) on return from setup.
> > This breaks the idea that we don't do anything unless
On Sunday 08 March 2009, Mark Brown wrote:
> On Sun, Mar 08, 2009 at 12:54:35PM -0800, David Brownell wrote:
>
> > but the bootloader turned the regulator on, then drivers
> > can't disable the regulator (on penalty of a stackdump!)
> > unless they issue a spurious/pointless/undesirable enable()
>
On Sun, Mar 08, 2009 at 12:54:35PM -0800, David Brownell wrote:
> but the bootloader turned the regulator on, then drivers
> can't disable the regulator (on penalty of a stackdump!)
> unless they issue a spurious/pointless/undesirable enable()
> beforehand ...
We can't easily have both reference
On Saturday 07 March 2009, Mark Brown wrote:
> What's happening here is that the kernel is making sure that the
> information it was given about the state of the regulator is actually
> true in case it was important ...
If that's a goal, then I suggest merging the appended patch,
which addresses a
On Fri, Mar 06, 2009 at 04:07:16PM -0800, David Brownell wrote:
> The boot_on semantics are kind of odd then ...
> What I thought they meant: Bootloader turned this on.
That's still roughly the case, though in practice there's no actual need
to do this for the vast majority of regulators since
On Friday 06 March 2009, Mark Brown wrote:
> > Later, I found out that in set_machine_constraints(),ops->enable() is
> > being called if the boot_on flag is set. What is the purpose of doing
> > this? Since the regulator is already enabled, why we are calling the
> > ops->enable() to do the same ag
On Thu, Mar 05, 2009 at 05:33:55PM +0530, Aggarwal, Anuj wrote:
[Please fix your mail client to wrap lines at ~80 columns - not doing so
makes your mails much harder to read and reply to.]
> But still when I call regulator_disable() after doing a _get() on it,
> the call fails saying " unbalanced
5 PM
> To: Aggarwal, Anuj
> Cc: linux-omap@vger.kernel.org
> Subject: Re: Problems while designing TPS65023 regulator driver
>
> On Thu, Feb 26, 2009 at 02:41:54PM +0530, Aggarwal, Anuj wrote:
>
> > Since all the five regulators can be controlled using a single i2c
> >
On Thu, Feb 26, 2009 at 02:41:54PM +0530, Aggarwal, Anuj wrote:
> Since all the five regulators can be controlled using a single i2c
> device, I made a single i2c_board_info structure in my platform
> specific file and put all the regulator_init_data information there:
This is very common - most
18 matches
Mail list logo
