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 alo
>
> 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.
>
>
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 framew
> > 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
> > 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 batte
>
> >> +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_noti
> +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
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 Se
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
> 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: 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
> > +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 ((te
: David 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 at 11:
> >
> > > 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 co
> 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
> th
> 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
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
> class.
>
> 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
> > > event
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,
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
>
> > > +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
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 wa
> > 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
> dri
> > 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 a
> 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
> 12b79d69a2b9f06
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
>
> 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 possib
> > > 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 char
> 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 propert
> >> 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
> >> > > 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
> > > 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, neve
> 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 o
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]
> 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
> > > > >
> > > > > 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
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
> 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
> >
> 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 propert
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 charge
45 matches
Mail list logo
