Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Felipe Contreras <felipe.contreras@nokia.com>,
	linux-main <linux-kernel@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Aliaksei Katovich <aliaksei.katovich@nokia.com>,
	Vladimir Zapolskiy <vz@mleia.com>
Subject: Re: [PATCH] mfd: add bq2415x charger driver
Date: Tue, 06 Dec 2011 08:25:49 +0100	[thread overview]
Message-ID: <8650361.EbH1hYJT76@pali-elitebook> (raw)
In-Reply-To: <CAMP44s1TrRkcy-xS+fXMyv0FAL1TnsPnnTa=gHSd2=P=iFkSUg@mail.gmail.com>

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

Hi,

On Tuesday 06 December 2011 02:12:47 you wrote:
> Hi,
> 
> On Tue, Dec 6, 2011 at 1:05 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > I started writing other implementaion of bq2415x charger driver, which
> > should support also setting usb host mode. Code is still unfinished,
> > but now is devided into 2 parts: one power_supply driver and one driver
> > which cover all bq registers. See:
> > 
> > http://atrey.karlin.mff.cuni.cz/~pali/bq2415x/
> > 
> > Felipe Contreras, I think that my implementation is better - it will
> > export all bq registers (which is needed for hostmode boost) and will
> > also register regulator interface.
> 
> I took a look at your driver, and there's definitely good stuff in it.
> However, I think there's a lot of unnecessary stuff, like the
> miscdevice stuff (which was frowned upon for bq27x00), and a lot of
> user-space interface. Moreover, it doesn't seem to do anything on its
> own (it needs interaction from user-space).

Ignore miscdevice, I will remove them from driver. I will add some debugfs 
interface for getting registers output (needed for debugging)

> 
> IMO the first step should be to have a minimal driver that just works,
> even if it doesn't achieve the absolute best charging performance.
> More features could be added later on.
> 
> Also, I'm not familiar with the regulator interface, but it seems to
> be meant for real regulators, which have consumers, and based on those
> consumers's needs the real voltage changes. This battery charger on
> the other hand doesn't have anything like that. There will be no
> consumer, and some stuff like the weak battery voltage is not even
> related to a voltage supply, but rather a threshold that can be
> configured to change some behavior of the charger, but there's no
> point in changing it dynamically (or maybe at all).

If regulator interface is not good, I can change it to some sysfs interface. 
But bq2415x chip driver is not only rx51 specified, so it should handle all 
chip capabilities.

> 
> I guess the important one is the charge voltage, which is linked to a
> real voltage, but what consumers would it have? I don't think there's
> any.
> 
> Finally, I don't think user-space interaction should be needed at all.
> The driver should start charging immediately when there power supply
> available, and stop when there isn't any. Maybe at some point a
> user-space interface will be useful later on (I don't see why), but I
> don't think it should be *necessary*.

Userspace interfaction is needed. We need to tell driver to boost - for usb 
host mode. But of course, battery charging should be automatic without 
userspace interfaction. 

> 
> I'm not familiar with any of this stuff, so don't take my opinions too
> seriously :)

Consider my code. We do not need two (or more) implementation of same driver 
in kernel. And also we do not need only rx51 specified code.

I separated bq2415x register access into one module (bq2415x.c - without any 
logic, only cover chip options) and real battery charging should be done in 
power_supply interface (bq2415x_charger.c)

My code has also prepaired boost support - for usb host mode, which must be 
done in driver.

If you do not agree with other parts, tell me about it - we can fix it.

> 
> Cheers.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2011-12-06  7:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-05 22:35 [PATCH] mfd: add bq2415x charger driver Felipe Contreras
2011-12-05 22:51 ` Felipe Contreras
2011-12-05 23:05 ` Pali Rohár
2011-12-06  0:12   ` Felipe Contreras
2011-12-06  7:25     ` Pali Rohár [this message]
2011-12-06 10:58       ` Felipe Contreras
2011-12-06 13:27         ` Pali Rohár
2011-12-06 14:11           ` Felipe Contreras
2011-12-06 15:19             ` Pali Rohár
2011-12-06 11:25       ` Mark Brown
2011-12-06  2:17 ` Sebastian Reichel
2011-12-06  2:49   ` Felipe Contreras
2011-12-06 13:21     ` Sebastian Reichel
2011-12-06 13:50       ` Felipe Contreras
2011-12-06 13:34     ` Pali Rohár
2011-12-06 11:31 ` Mark Brown
2011-12-06 11:43   ` Felipe Contreras
2011-12-06 11:46     ` Mark Brown
2011-12-07 21:03 ` RFC: bq2415x_charger driver Pali Rohár
2011-12-07 21:25   ` Vladimir Zapolskiy
2011-12-07 21:40     ` Pali Rohár
2012-01-27  2:40   ` RFC 2: " Pali Rohár
2012-01-27 16:24     ` Mark Brown
2012-01-27 18:33       ` Pali Rohár
2012-01-27 19:22         ` Mark Brown
2012-01-27 20:40     ` Sebastian Reichel

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=8650361.EbH1hYJT76@pali-elitebook \
    --to=pali.rohar@gmail.com \
    --cc=aliaksei.katovich@nokia.com \
    --cc=felipe.contreras@gmail.com \
    --cc=felipe.contreras@nokia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=vz@mleia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox