Hi,
> On Fri, Mar 06, 2015 at 04:03:27PM +0530, Jenny TC wrote:
> > At present charger manager support only regulator based charging
> > control. But most of the charger drivers are registered with power
> > supply subsystem. This patch adds support for power supply based
> > charging control
>
> On Mon, Mar 09, 2015 at 12:26:21PM +0000, Tc, Jenny wrote:
> > > > + char name[PSY_MAX_BAT_NAME_LEN];
> > >
> > > char *name;
> > >
> > > No need for arbitrary length limitation.
> >
> > The length limitation is intr
Hi,
> > +struct power_supply_charger {
> > + int (*get_property)(struct power_supply_charger *psyc,
> > + enum psy_charger_control_property pspc,
> > + union power_supply_propval *val);
>
> The charging framework can simply call the same get_property
Hi,
> > +#define PSY_MAX_BAT_NAME_LEN 8
> > +#define PSY_MAX_TEMP_ZONE 6
> > +
> > +struct psy_charging_obj {
>
> This is not just about charging data, but also about the batteries
> thermal limits, technology and full capacity, so how about
>
> struct psy_battery_information {
Ok, Agree.
>
Hi,
+#define PSY_MAX_BAT_NAME_LEN 8
+#define PSY_MAX_TEMP_ZONE 6
+
+struct psy_charging_obj {
This is not just about charging data, but also about the batteries
thermal limits, technology and full capacity, so how about
struct psy_battery_information {
Ok, Agree.
+ char
Hi,
+struct power_supply_charger {
+ int (*get_property)(struct power_supply_charger *psyc,
+ enum psy_charger_control_property pspc,
+ union power_supply_propval *val);
The charging framework can simply call the same get_property
as used
Hi,
On Fri, Mar 06, 2015 at 04:03:27PM +0530, Jenny TC wrote:
At present charger manager support only regulator based charging
control. But most of the charger drivers are registered with power
supply subsystem. This patch adds support for power supply based
charging control along with
On Mon, Mar 09, 2015 at 12:26:21PM +, Tc, Jenny wrote:
+ char name[PSY_MAX_BAT_NAME_LEN];
char *name;
No need for arbitrary length limitation.
The length limitation is introduced to form a packed structure so that
the data can be read directly from memory without
Sebastian,
I would appreciate if you could share your plans on this patch?. As you agreed
on
the IRC session, can you push this patch to staging? Meanwhile we will work to
close the TODOs captured in the IRC session (http://elektranox.org/battery.txt)
-Jenny
> v1: Introduced feature as a
> > The CC/CV for each battery temperature zone is defined as part of battery
> > spec.
> This is
> > as per the JEITA/PSE standards. So IMO, this is a battery charging
> > information
> > (charging object) rather than a thermal throttling information.
> >
> > Also the battery information may
The CC/CV for each battery temperature zone is defined as part of battery
spec.
This is
as per the JEITA/PSE standards. So IMO, this is a battery charging
information
(charging object) rather than a thermal throttling information.
Also the battery information may not fit into a
Sebastian,
I would appreciate if you could share your plans on this patch?. As you agreed
on
the IRC session, can you push this patch to staging? Meanwhile we will work to
close the TODOs captured in the IRC session (http://elektranox.org/battery.txt)
-Jenny
v1: Introduced feature as a
> > The CC,CV and restart threshold would vary based on the battery temperature
> > So I would suggest to have temperature zone table as part of battery info
> > along with other attributes.
> >
> > int iterm; //charge termination current (used to stop charging)
> > int temp_zone_count; // number
> @@ -241,6 +241,8 @@ struct power_supply_info {
> int charge_empty_design;
> int energy_full_design;
> int energy_empty_design;
> + int temperature_max;
> + int temperature_min;
> int use_for_apm;
> };
The CC,CV and restart threshold would vary based on the
@@ -241,6 +241,8 @@ struct power_supply_info {
int charge_empty_design;
int energy_full_design;
int energy_empty_design;
+ int temperature_max;
+ int temperature_min;
int use_for_apm;
};
The CC,CV and restart threshold would vary based on the battery
The CC,CV and restart threshold would vary based on the battery temperature
So I would suggest to have temperature zone table as part of battery info
along with other attributes.
int iterm; //charge termination current (used to stop charging)
int temp_zone_count; // number of
>
> >> +ATOMIC_NOTIFIER_HEAD(psy_battery_info_notifier);
> >
> > Isn't it good to reuse the existing power_supply_notifier for this?
> >
> >> +enum battery_info_notifier_events {
> >> + PSY_BATT_INFO_REGISTERED,
> >> + PSY_BATT_INFO_UNREGISTERED,
> >> +};
> >
> > If we use the
+ATOMIC_NOTIFIER_HEAD(psy_battery_info_notifier);
Isn't it good to reuse the existing power_supply_notifier for this?
+enum battery_info_notifier_events {
+ PSY_BATT_INFO_REGISTERED,
+ PSY_BATT_INFO_UNREGISTERED,
+};
If we use the power_supply_notifier, then this can be
> +ATOMIC_NOTIFIER_HEAD(psy_battery_info_notifier);
Isn't it good to reuse the existing power_supply_notifier for this?
> +enum battery_info_notifier_events {
> + PSY_BATT_INFO_REGISTERED,
> + PSY_BATT_INFO_UNREGISTERED,
> +};
If we use the power_supply_notifier, then this can be moved
+ATOMIC_NOTIFIER_HEAD(psy_battery_info_notifier);
Isn't it good to reuse the existing power_supply_notifier for this?
+enum battery_info_notifier_events {
+ PSY_BATT_INFO_REGISTERED,
+ PSY_BATT_INFO_UNREGISTERED,
+};
If we use the power_supply_notifier, then this can be moved to
If the intention is to prevent suspend while processing the power supply
uevents,
Isn't it a good option to use EPOLLWAKEUP? In Android, it's already used by
healthd to achieve the same.
-Jenny
> Subject: Re: [RFC PATCH] pm: prevent suspend until power supply events are
> processed
>
> On 4
If the intention is to prevent suspend while processing the power supply
uevents,
Isn't it a good option to use EPOLLWAKEUP? In Android, it's already used by
healthd to achieve the same.
-Jenny
Subject: Re: [RFC PATCH] pm: prevent suspend until power supply events are
processed
On 4
Ping...
> -Original Message-
> From: Tc, Jenny
> Sent: Wednesday, August 13, 2014 5:40 PM
> To: linux-kernel@vger.kernel.org; Sebastian Reichel; Pavel Machek
> Cc: Dmitry Eremin-Solenikov; Stephen Rothwell; Anton Vorontsov; David
> Woodhouse; David Cohen; Pallala, Rama
Ping...
-Original Message-
From: Tc, Jenny
Sent: Wednesday, August 13, 2014 5:40 PM
To: linux-kernel@vger.kernel.org; Sebastian Reichel; Pavel Machek
Cc: Dmitry Eremin-Solenikov; Stephen Rothwell; Anton Vorontsov; David
Woodhouse; David Cohen; Pallala, Ramakrishna; Tc, Jenny
> From: Sebastian Reichel [mailto:s...@kernel.org]
> Sent: Friday, July 18, 2014 7:49 AM
> To: Tc, Jenny
> Cc: linux-kernel@vger.kernel.org; Dmitry Eremin-Solenikov; Pavel Machek; Anton
> Vorontsov; David Woodhouse; David Cohen; Pallala, Ramakrishna;
> myungjoo@samsung
From: Sebastian Reichel [mailto:s...@kernel.org]
Sent: Friday, July 18, 2014 7:49 AM
To: Tc, Jenny
Cc: linux-kernel@vger.kernel.org; Dmitry Eremin-Solenikov; Pavel Machek; Anton
Vorontsov; David Woodhouse; David Cohen; Pallala, Ramakrishna;
myungjoo@samsung.com
Subject: Re: [PATCH 2/4
> From: Sebastian Reichel [mailto:s...@kernel.org]
> Sent: Tuesday, July 08, 2014 9:26 PM
> To: Tc, Jenny
> Cc: linux-kernel@vger.kernel.org; Dmitry Eremin-Solenikov; Pavel Machek;
> Stephen
> Rothwell; Anton Vorontsov; David Woodhouse; David Cohen; Pallala, Ramakrishna
> Su
From: Sebastian Reichel [mailto:s...@kernel.org]
Sent: Tuesday, July 08, 2014 9:26 PM
To: Tc, Jenny
Cc: linux-kernel@vger.kernel.org; Dmitry Eremin-Solenikov; Pavel Machek;
Stephen
Rothwell; Anton Vorontsov; David Woodhouse; David Cohen; Pallala, Ramakrishna
Subject: Re: [PATCH 3/4
> > +static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof,
> > + int temp)
> > +{
> > + int i = 0;
> > + int temp_range_cnt;
> > +
> > + temp_range_cnt = min_t(u16, pse_mod_bprof->temp_mon_ranges,
> > + BATT_TEMP_NR_RNG);
> > + if
+static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof,
+ int temp)
+{
+ int i = 0;
+ int temp_range_cnt;
+
+ temp_range_cnt = min_t(u16, pse_mod_bprof-temp_mon_ranges,
+ BATT_TEMP_NR_RNG);
+ if ((temp
id Woodhouse; Tony Lindgren; Russell King;
> linux-kernel@vger.kernel.org;
> linux-o...@vger.kernel.org; freemangor...@abv.bg; aaro.koski...@iki.fi;
> pa...@ucw.cz; Tc, Jenny
> Subject: Re: [PATCH v2 1/3] power_supply: Add power_supply notifier
>
> On Tue, Nov 19, 2013 a
Lindgren; Russell King;
linux-kernel@vger.kernel.org;
linux-o...@vger.kernel.org; freemangor...@abv.bg; aaro.koski...@iki.fi;
pa...@ucw.cz; Tc, Jenny
Subject: Re: [PATCH v2 1/3] power_supply: Add power_supply notifier
On Tue, Nov 19, 2013 at 11:18:03AM +0100, Pali Rohár wrote:
This patch adds
> >
> > > On Mon, Oct 28, 2013 at 03:36:36AM +, Tc, Jenny wrote:
> > > > > But do we really want to control the chargers through the
> > > > > power_supply's user-visible interface? It makes the whole power
> > > > > supply thing so complic
> Subject: [PATCH v2 1/3] power_supply: Add power_supply notifier
>
> This patch adds a notifier chain to the power_supply.
> This notifier helps drivers in other subsystem to listen to changes in power
> supply
> subsystem. This would help to take some actions in those drivers on changing
>
in power_suppy susbystem without polling the power_supply
properties
Signed-off-by: Jenny TC jenny...@intel.com
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
Acked-by: Jenny TC jenny...@intel.com
, 2013 at 03:36:36AM +, Tc, Jenny wrote:
But do we really want to control the chargers through the
power_supply's user-visible interface? It makes the whole power
supply thing so complicated that I'm already losing track of it.
Right now I think I would prefer to move all
> Subject: Re: [PATCH 1/7] power_supply: Add charger control properties
>
> On Sun, 27 Oct 2013 23:18:08 -0700 Anton Vorontsov wrote:
>
> > On Mon, Oct 28, 2013 at 03:36:36AM +, Tc, Jenny wrote:
> > > > But do we really want to control the chargers through t
Subject: Re: [PATCH 1/7] power_supply: Add charger control properties
On Sun, 27 Oct 2013 23:18:08 -0700 Anton Vorontsov an...@enomsg.org wrote:
On Mon, Oct 28, 2013 at 03:36:36AM +, Tc, Jenny wrote:
But do we really want to control the chargers through the
power_supply's user
Anton,
> But do we really want to control the chargers through the power_supply's
> user-visible
> interface? It makes the whole power supply thing so complicated that I'm
> already losing
> track of it. Right now I think I would prefer to move all the charger logic
> out of the psy
>
>
> On Saturday 26 October 2013 02:25:02 Sebastian Reichel wrote:
> > Hi Pali,
> >
> > On Fri, Oct 25, 2013 at 08:39:40PM +0200, Pali Rohár wrote:
> > > Now I found this patch and it looks like it will be in mainline
> > > kernel. And after that it could be simple to listen for needed
> > >
On Saturday 26 October 2013 02:25:02 Sebastian Reichel wrote:
Hi Pali,
On Fri, Oct 25, 2013 at 08:39:40PM +0200, Pali Rohár wrote:
Now I found this patch and it looks like it will be in mainline
kernel. And after that it could be simple to listen for needed
events from isp
power_supply_charger.c can
be a separate driver and it can listen to psy notifications to take actions.
Thanks,
Anton
Signed-off-by: Jenny TC jenny...@intel.com
Change-Id: Id91dbbd8f34499afa97b7d8f11ecf5467847f6a8
---
Documentation/power/power_supply_class.txt | 16
drivers
Anton,
Could you please review these patches?
-Jenny
> -Original Message-
> From: Tc, Jenny
> Sent: Monday, September 23, 2013 11:34 PM
> To: linux-kernel@vger.kernel.org; Anton Vorontsov; Anton Vorontsov
> Cc: Tc, Jenny
> Subject: [PATCH 0/7] power_supply: Intr
Anton,
Could you please review these patches?
-Jenny
-Original Message-
From: Tc, Jenny
Sent: Monday, September 23, 2013 11:34 PM
To: linux-kernel@vger.kernel.org; Anton Vorontsov; Anton Vorontsov
Cc: Tc, Jenny
Subject: [PATCH 0/7] power_supply: Introduce Power Supply Charging
Anton,
I submitted 7 patches together which includes this patch also. Hope this would
give more insight to the features.
-Jenny
> -Original Message-
> From: Anton Vorontsov [mailto:an...@scarybugs.org] On Behalf Of Anton
> Vorontsov
> Sent: Saturday, August 10, 2013 12:27
thresholds based on battery
voltage/capacity. The notifier helps drivers to listen to changes in
power_suppy susbystem without polling the power_supply properties
Signed-off-by: Jenny TC jenny...@intel.com
---
Hi Jenny,
Can you please submit users of this new API as well, so that we could
>
> > > +struct power_supply_charger_control {
> > > + const char *name;
> > > + /* get charging status */
> > > + int (*is_charging_enabled)(void);
> > > + int (*is_charger_enabled)(void);
> > > +
> > > + /* set charging parameters */
> > > + int (*set_in_current_limit)(int uA);
> > > + int
+struct power_supply_charger_control {
+ const char *name;
+ /* get charging status */
+ int (*is_charging_enabled)(void);
+ int (*is_charger_enabled)(void);
+
+ /* set charging parameters */
+ int (*set_in_current_limit)(int uA);
+ int (*set_charge_current)(int uA);
Anton,
Could you please have a look at my comments below?
-jtc
> > While I see nothing wrong with the patch itself, I beg you to send
> > some users for the new calls. Don't be obsessed with the extcon
> > internals too much, think more about how things will interact (i.e. I
> > really really
> > I replied on the thread and pointed out issues that I see with this
> > solution. IMHO It's not fair to register a cable with
> > power_supply/regulator/charger manager just to expose the cable
> properties.
> Don't we do that with already in allmost all drivers?Like if I have a keyboard
>
I replied on the thread and pointed out issues that I see with this
solution. IMHO It's not fair to register a cable with
power_supply/regulator/charger manager just to expose the cable
properties.
Don't we do that with already in allmost all drivers?Like if I have a keyboard
driver and
Anton,
Could you please have a look at my comments below?
-jtc
While I see nothing wrong with the patch itself, I beg you to send
some users for the new calls. Don't be obsessed with the extcon
internals too much, think more about how things will interact (i.e. I
really really want to
> > Could you please review this. This is a follow up patch for "PATCH]
> > extcon : callback function to read cable property"
>
> While I see nothing wrong with the patch itself, I beg you to send some users
> for the new calls. Don't be obsessed with the extcon internals too much,
> think more
> We discussed about this patch and then suggest some method to resolve this
> issue by Myungjoo Ham. Why don't you write additional feature or your
> opinion based on following patch by Myungjoo Ham?
> -
> http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commitdiff;h=73
>
the
extcon_cable_get_data() to get the cable properties irrespective of
who provides the cable data.
This gives a single interface for setting and getting the cable properties.
Signed-off-by: Jenny TC jenny...@intel.com
---
drivers/extcon/extcon-class.c | 30
Could you please review this. This is a follow up patch for PATCH]
extcon : callback function to read cable property
While I see nothing wrong with the patch itself, I beg you to send some users
for the new calls. Don't be obsessed with the extcon internals too much,
think more about how
Hi Myungjoo/Chanwoo/Aneesh/Anton,
Could you please review this. This is a follow up patch for "PATCH] extcon :
callback function to read cable property"
-jtc
> Subject: [PATCH] EXTCON: Get and set cable properties
>
> Existing EXTCON implementation doesn't give a mechanim to read the cable
>
of who
provides the cable data.
This gives a single interface for setting and getting the cable properties.
Signed-off-by: Jenny TC jenny...@intel.com
---
drivers/extcon/extcon-class.c | 30 ++
include/linux/extcon.h| 39
> The "RFC" patch for this feature is now shown at:
> http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commit;h=5655a
> eef83addaec77a3b9387a3dd18b6c146dd5
> (Note that "for-add-feature" branch is sort of "RFC" branch)
>
> I'm now considering relaying notifications of data updates
The RFC patch for this feature is now shown at:
http://git.kernel.org/?p=linux/kernel/git/mzx/extcon.git;a=commit;h=5655a
eef83addaec77a3b9387a3dd18b6c146dd5
(Note that for-add-feature branch is sort of RFC branch)
I'm now considering relaying notifications of data updates possible via the
> > > For example,
> > > Firstly, the power_supply charging framework check state of charger
> > > cable whether attached or detached cable. Second, when power_supply
> > > charging framework receive the changed state of host system from
> > > 'Host system notifier', change charging current of
> I think that the role of extcon subsystem notify changed
> state(attached/detached) of cable to notifiee, but if you want
> to add property feature of cable, you should solve ambiguous
> issues.
>
> First,
> This patch only support the
I think that the role of extcon subsystem notify changed
state(attached/detached) of cable to notifiee, but if you want
to add property feature of cable, you should solve ambiguous
issues.
First,
This patch only support the properties of charger cable but,
never support property of
For example,
Firstly, the power_supply charging framework check state of charger
cable whether attached or detached cable. Second, when power_supply
charging framework receive the changed state of host system from
'Host system notifier', change charging current of charger cable.
> >> I think that the role of extcon subsystem notify changed
> >> state(attached/detached) of cable to notifiee, but if you want to
> >> add property feature of cable, you should solve ambiguous issues.
> >>
> >> First,
> >> This patch only support the properties of
> >> > > I think that the role of extcon subsystem notify changed
> >> > > state(attached/detached) of cable to notifiee, but if you want to
> >> > > add property feature of cable, you should solve ambiguous issues.
> >> > >
> >> > > First,
> >> > > This patch only support the properties of
I think that the role of extcon subsystem notify changed
state(attached/detached) of cable to notifiee, but if you want to
add property feature of cable, you should solve ambiguous issues.
First,
This patch only support the properties of charger cable but,
never support
I think that the role of extcon subsystem notify changed
state(attached/detached) of cable to notifiee, but if you want to
add property feature of cable, you should solve ambiguous issues.
First,
This patch only support the properties of charger cable but,
never support property of
> > > I think that the role of extcon subsystem notify changed
> > > state(attached/detached) of cable to notifiee, but if you want to
> > > add property feature of cable, you should solve ambiguous issues.
> > >
> > > First,
> > > This patch only support the properties of charger cable but,
I think that the role of extcon subsystem notify changed
state(attached/detached) of cable to notifiee, but if you want to
add property feature of cable, you should solve ambiguous issues.
First,
This patch only support the properties of charger cable but, never
support
> I think that the role of extcon subsystem notify changed
> state(attached/detached) of cable to notifiee, but if you want to add
> property feature of cable, you should solve ambiguous issues.
>
> First,
> This patch only support the properties of charger cable but, never support
> property of
I think that the role of extcon subsystem notify changed
state(attached/detached) of cable to notifiee, but if you want to add
property feature of cable, you should solve ambiguous issues.
First,
This patch only support the properties of charger cable but, never support
property of other
Myunjoo,
Ping. Could you please have a look at my response below?
-jtc
> -Original Message-
> From: Tc, Jenny
> Sent: Thursday, October 25, 2012 2:55 PM
> To: myungjoo@samsung.com; ???
> Cc: linux-kernel@vger.kernel.org; anish kumar
> Subject: RE: RE: [PATCH]
Myunjoo,
Ping. Could you please have a look at my response below?
-jtc
-Original Message-
From: Tc, Jenny
Sent: Thursday, October 25, 2012 2:55 PM
To: myungjoo@samsung.com; ???
Cc: linux-kernel@vger.kernel.org; anish kumar
Subject: RE: RE: [PATCH] extcon : callback function
> Subject: Re: RE: [PATCH] extcon : callback function to read cable property
> > For charger cable the current each cable can provide will be common.
> > But may not be relevant for other cables.
> >
> > I understand your point on extcon role. But my concern is, when the
> > consumer driver gets a
Subject: Re: RE: [PATCH] extcon : callback function to read cable property
For charger cable the current each cable can provide will be common.
But may not be relevant for other cables.
I understand your point on extcon role. But my concern is, when the
consumer driver gets a
> Subject: Re: [PATCH] extcon : callback function to read cable property
>
> On 10/19/2012 12:13 PM, Tc, Jenny wrote:
> >
> >
> >>>>>> Subject: Re: [PATCH] extcon : callback function to read cable
> >>>>>> property
> >&
Subject: Re: [PATCH] extcon : callback function to read cable property
On 10/19/2012 12:13 PM, Tc, Jenny wrote:
Subject: Re: [PATCH] extcon : callback function to read cable
property
I think the reason why we have extcon is in first place is to
only notify the clients of cable
> > > > > Subject: Re: [PATCH] extcon : callback function to read cable
> > > > > property
> > > > >
> > > > > I think the reason why we have extcon is in first place is to
> > > > > only notify the clients of cable connection and disconnection
> > > > > and it is up to the client to decide what
Anton Vorontsov; Anton Vorontsov; dw...@infradead.org; linux-
> ker...@vger.kernel.org
> Cc: Tc, Jenny; David Rajamanickam, Ajay Thomas; Pallala, Ramakrishna
> Subject: [PATCH V2] power_supply : Introduce battery identification
> framework
>
> This patch introduces generic battid fr
Vorontsov; dw...@infradead.org; linux-
ker...@vger.kernel.org
Cc: Tc, Jenny; David Rajamanickam, Ajay Thomas; Pallala, Ramakrishna
Subject: [PATCH V2] power_supply : Introduce battery identification
framework
This patch introduces generic battid framework. Different battid drivers
sitting
Subject: Re: [PATCH] extcon : callback function to read cable
property
I think the reason why we have extcon is in first place is to
only notify the clients of cable connection and disconnection
and it is up to the client to decide what else to do with the
Myunjoo/Chanwoo
Ping...
Could you please review this patch?
-jtc
> > > Subject: Re: [PATCH] extcon : callback function to read cable
> > > property
> > >
> > > I think the reason why we have extcon is in first place is to only
> > > notify the clients of cable connection and disconnection and
Myunjoo/Chanwoo
Ping...
Could you please review this patch?
-jtc
Subject: Re: [PATCH] extcon : callback function to read cable
property
I think the reason why we have extcon is in first place is to only
notify the clients of cable connection and disconnection and it is
up to
> Subject: Re: [PATCH] extcon : register for cable interest by cable name
>
> > There are some scnearios where a driver/framework needs to register
> > interest for a particular cable without specifying the extcon device
> > name. One such scenario is charger notifications. The platform will
>
charger cabel which will be bound to any extcon device. It's not
mandatory for the charger driver to know which extcon device it should
use. This patch enables the support for registering interest for a
cable just by cable name wihtout specifying the extcon device name
Signed-off-by: Jenny TC
> From: anish kumar [mailto:anish198519851...@gmail.com]
> Sent: Wednesday, October 10, 2012 8:15 PM
> To: Tc, Jenny
> Cc: myungjoo@samsung.com; cw00.c...@samsung.com; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] extcon : callback function to read cable pro
From: anish kumar [mailto:anish198519851...@gmail.com]
Sent: Wednesday, October 10, 2012 8:15 PM
To: Tc, Jenny
Cc: myungjoo@samsung.com; cw00.c...@samsung.com; linux-
ker...@vger.kernel.org
Subject: Re: [PATCH] extcon : callback function to read cable property
I think the reason why
Anton,
> Hm. So Myungjoo thinks that some of the features are compatible. Which do
> you guys think are not compatible? Is this because charger manager does
> everything using a regulator framework? That is, quoting you:
>
> "The challenge I see in implementing the above requirements in
Anton,
Hm. So Myungjoo thinks that some of the features are compatible. Which do
you guys think are not compatible? Is this because charger manager does
everything using a regulator framework? That is, quoting you:
The challenge I see in implementing the above requirements in charger
90 matches
Mail list logo
