All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gene Chen <gene.chen.richtek@gmail.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-pm@vger.kernel.org, devicetree <devicetree@vger.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Gene Chen <gene_chen@richtek.com>,
	Wilma.Wu@mediatek.com, shufan_lee@richtek.com,
	ChiYuan Huang <cy_huang@richtek.com>,
	benjamin.chao@mediatek.com
Subject: Re: [PATCH v3 2/2] power: supply: mt6360_charger: add MT6360 charger support
Date: Mon, 18 Jan 2021 15:58:44 +0800	[thread overview]
Message-ID: <CAE+NS34dKX+Zrzp3zzL2-NFvh7FrCUEminVT8jMBDOvS1ZQH9w@mail.gmail.com> (raw)
In-Reply-To: <20210116101237.vktppv2ec7kvtz3v@earth.universe>

Sebastian Reichel <sebastian.reichel@collabora.com> 於 2021年1月16日 週六 下午6:12寫道:
>
> Hi,
>
> On Mon, Jan 11, 2021 at 08:15:33PM +0800, Gene Chen wrote:
> > Sebastian Reichel <sebastian.reichel@collabora.com> 於 2021年1月7日 週四 上午4:16寫道:
> > > > +     last_usb_type = mci->psy_usb_type;
> > > > +     /* Plug in */
> > > > +     ret = regmap_read(mci->regmap, MT6360_PMU_USB_STATUS1, &usb_status);
> > > > +     if (ret < 0)
> > > > +             goto out;
> > > > +     usb_status &= MT6360_USB_STATUS_MASK;
> > > > +     usb_status >>= MT6360_USB_STATUS_SHFT;
> > > > +     switch (usb_status) {
> > > > +     case MT6360_CHG_TYPE_UNDER_GOING:
> > > > +             dev_info(mci->dev, "%s: under going...\n", __func__);
> > > > +             goto out;
> > >
> > > IDK what this is supposed to tell me. Do you mean "detection in
> > > progress"? Also why is this info level? I would expect either
> > > debug (assuming it happens regularly and is normal) or warning
> > > (assuming it should not happen).
> > >
> >
> > When handling attach interrupt and cable plug out at the same
> > time, HW change register status. So we don' need to handle this
> > attach interrupt at this case.
>
> So this is basically for debouncing? I suggest adding a comment:
>
> /* Received attach IRQ followed by detach event, so nothing to do */
> dev_dbg(mci->dev, "under going...\n");
> goto out;
>

Sorry I have a little misunderstand.
under going is "detect in progress".
Attachi irq will trigger when power ready(vbus=5V) and bc12
chargedetection done.
Another irq, Detachi, is indicated power not ready(vbus=0V) and which
is be masked.
So, if the usb status is not SDP/NONSTD/CDP/DCP, the result can be
ignored. (e.q. NO VBUS/Under going/BC12 disabled/Reserved address)

> [...]
>
> > > > +     config.dev = &pdev->dev;
> > > > +     config.regmap = mci->regmap;
> > > > +     mci->otg_rdev = devm_regulator_register(&pdev->dev, &mt6360_otg_rdesc,
> > > > +                                             &config);
> > > > +     if (IS_ERR(mci->otg_rdev))
> > > > +             return PTR_ERR(mci->otg_rdev);
> > > > +
> > > > +     ret = mt6360_sysfs_create_group(mci);
> > > > +     if (ret) {
> > > > +             dev_err(&pdev->dev,
> > > > +                     "%s: Failed to create sysfs attrs\n", __func__);
> > > > +             return ret;
> > > > +     }
> > >
> > > Use charger_cfg.attr_grp to register custom sysfs group for
> > > power-supply devices. Otherwise your code is racy (udev may not pick
> > > up the sysfs attributes). Also custom sysfs attributes need to be
> > > documented in Documentation/ABI/testing/sysfs-class-power-<driver>.
> > >
> > > Looking at the attributes you are planning to expose, I don't think they
> > > are suitable for sysfs anyways. Looks more like a debug interface, which
> > > should go into debugfs instead. But it's hard to tell without any documentation
> > > being provided :)
> >
> > ACK, I will change to charger_cfg.attr_grp.
> > I assumed the charger algorithm thread is in user space, and take
> > control by sysfs node from charger device, like bq24190.c.
> > Should I change to debugfs?
>
> It's hard to tell without knowing more about the attributes
> your are trying to expose. In debugfs we have relaxed ABI rules,
> so it's easier to adopt naming e.t.c. later.
>

I briefly classify the whole attributes. There are either unused, or
can be replaced by POWER_SUPPLY PROPERTY,
so I will remove unuse part.

HIZ = VBUS_IN high impedance mode.
VMIVR = Maximum input voltage regulation. Let input power can provide
at the predetermined voltage level.
(like POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT)
SYSREG = Config system minimum regulation voltage.
OTG_OC = maximum current of battery boost OTG 5V.
ICHG = maximum Charging current. (like
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT)
IEOC = Like POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT
VOREG = Input voltage regulation. (like
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE)
LBP = Low battery protection for battery boost OTG 5V.
VPREC = Pre-charge volatge level. (maybe can add new prop
POWER_SUPPLY_PROP_PRECHARGE_VOLTAGE)
TE = Charge termination enable/disable.
CHG_WDT_EN = Charger Watch dog timer enable/disable.
CHG_WDT = Charger Watch dog timer, 8/40/80/160s.
WT_FC = Fast charge Timer, 4~20hr.
BAT_COMP = Battery IR compensation resistor setting.
VCLAMP = Battery IR compensation maximum voltage clamp.
USBCHGEN = USB charger detection flow enable/disable.
CHG_EN = Battery charging enable/disable.
CHRDET_EXT = VBUS_IN is between VBUS_UV_TH(3.7V) and VBUS_OV_TH(10.5V)

> -- Sebastian

WARNING: multiple messages have this Message-ID (diff)
From: Gene Chen <gene.chen.richtek@gmail.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Gene Chen <gene_chen@richtek.com>,
	devicetree <devicetree@vger.kernel.org>,
	linux-pm@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ChiYuan Huang <cy_huang@richtek.com>,
	benjamin.chao@mediatek.com, Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Wilma.Wu@mediatek.com,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	shufan_lee@richtek.com
Subject: Re: [PATCH v3 2/2] power: supply: mt6360_charger: add MT6360 charger support
Date: Mon, 18 Jan 2021 15:58:44 +0800	[thread overview]
Message-ID: <CAE+NS34dKX+Zrzp3zzL2-NFvh7FrCUEminVT8jMBDOvS1ZQH9w@mail.gmail.com> (raw)
In-Reply-To: <20210116101237.vktppv2ec7kvtz3v@earth.universe>

Sebastian Reichel <sebastian.reichel@collabora.com> 於 2021年1月16日 週六 下午6:12寫道:
>
> Hi,
>
> On Mon, Jan 11, 2021 at 08:15:33PM +0800, Gene Chen wrote:
> > Sebastian Reichel <sebastian.reichel@collabora.com> 於 2021年1月7日 週四 上午4:16寫道:
> > > > +     last_usb_type = mci->psy_usb_type;
> > > > +     /* Plug in */
> > > > +     ret = regmap_read(mci->regmap, MT6360_PMU_USB_STATUS1, &usb_status);
> > > > +     if (ret < 0)
> > > > +             goto out;
> > > > +     usb_status &= MT6360_USB_STATUS_MASK;
> > > > +     usb_status >>= MT6360_USB_STATUS_SHFT;
> > > > +     switch (usb_status) {
> > > > +     case MT6360_CHG_TYPE_UNDER_GOING:
> > > > +             dev_info(mci->dev, "%s: under going...\n", __func__);
> > > > +             goto out;
> > >
> > > IDK what this is supposed to tell me. Do you mean "detection in
> > > progress"? Also why is this info level? I would expect either
> > > debug (assuming it happens regularly and is normal) or warning
> > > (assuming it should not happen).
> > >
> >
> > When handling attach interrupt and cable plug out at the same
> > time, HW change register status. So we don' need to handle this
> > attach interrupt at this case.
>
> So this is basically for debouncing? I suggest adding a comment:
>
> /* Received attach IRQ followed by detach event, so nothing to do */
> dev_dbg(mci->dev, "under going...\n");
> goto out;
>

Sorry I have a little misunderstand.
under going is "detect in progress".
Attachi irq will trigger when power ready(vbus=5V) and bc12
chargedetection done.
Another irq, Detachi, is indicated power not ready(vbus=0V) and which
is be masked.
So, if the usb status is not SDP/NONSTD/CDP/DCP, the result can be
ignored. (e.q. NO VBUS/Under going/BC12 disabled/Reserved address)

> [...]
>
> > > > +     config.dev = &pdev->dev;
> > > > +     config.regmap = mci->regmap;
> > > > +     mci->otg_rdev = devm_regulator_register(&pdev->dev, &mt6360_otg_rdesc,
> > > > +                                             &config);
> > > > +     if (IS_ERR(mci->otg_rdev))
> > > > +             return PTR_ERR(mci->otg_rdev);
> > > > +
> > > > +     ret = mt6360_sysfs_create_group(mci);
> > > > +     if (ret) {
> > > > +             dev_err(&pdev->dev,
> > > > +                     "%s: Failed to create sysfs attrs\n", __func__);
> > > > +             return ret;
> > > > +     }
> > >
> > > Use charger_cfg.attr_grp to register custom sysfs group for
> > > power-supply devices. Otherwise your code is racy (udev may not pick
> > > up the sysfs attributes). Also custom sysfs attributes need to be
> > > documented in Documentation/ABI/testing/sysfs-class-power-<driver>.
> > >
> > > Looking at the attributes you are planning to expose, I don't think they
> > > are suitable for sysfs anyways. Looks more like a debug interface, which
> > > should go into debugfs instead. But it's hard to tell without any documentation
> > > being provided :)
> >
> > ACK, I will change to charger_cfg.attr_grp.
> > I assumed the charger algorithm thread is in user space, and take
> > control by sysfs node from charger device, like bq24190.c.
> > Should I change to debugfs?
>
> It's hard to tell without knowing more about the attributes
> your are trying to expose. In debugfs we have relaxed ABI rules,
> so it's easier to adopt naming e.t.c. later.
>

I briefly classify the whole attributes. There are either unused, or
can be replaced by POWER_SUPPLY PROPERTY,
so I will remove unuse part.

HIZ = VBUS_IN high impedance mode.
VMIVR = Maximum input voltage regulation. Let input power can provide
at the predetermined voltage level.
(like POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT)
SYSREG = Config system minimum regulation voltage.
OTG_OC = maximum current of battery boost OTG 5V.
ICHG = maximum Charging current. (like
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT)
IEOC = Like POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT
VOREG = Input voltage regulation. (like
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE)
LBP = Low battery protection for battery boost OTG 5V.
VPREC = Pre-charge volatge level. (maybe can add new prop
POWER_SUPPLY_PROP_PRECHARGE_VOLTAGE)
TE = Charge termination enable/disable.
CHG_WDT_EN = Charger Watch dog timer enable/disable.
CHG_WDT = Charger Watch dog timer, 8/40/80/160s.
WT_FC = Fast charge Timer, 4~20hr.
BAT_COMP = Battery IR compensation resistor setting.
VCLAMP = Battery IR compensation maximum voltage clamp.
USBCHGEN = USB charger detection flow enable/disable.
CHG_EN = Battery charging enable/disable.
CHRDET_EXT = VBUS_IN is between VBUS_UV_TH(3.7V) and VBUS_OV_TH(10.5V)

> -- Sebastian

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Gene Chen <gene.chen.richtek@gmail.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Gene Chen <gene_chen@richtek.com>,
	devicetree <devicetree@vger.kernel.org>,
	linux-pm@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ChiYuan Huang <cy_huang@richtek.com>,
	benjamin.chao@mediatek.com, Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Wilma.Wu@mediatek.com,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	shufan_lee@richtek.com
Subject: Re: [PATCH v3 2/2] power: supply: mt6360_charger: add MT6360 charger support
Date: Mon, 18 Jan 2021 15:58:44 +0800	[thread overview]
Message-ID: <CAE+NS34dKX+Zrzp3zzL2-NFvh7FrCUEminVT8jMBDOvS1ZQH9w@mail.gmail.com> (raw)
In-Reply-To: <20210116101237.vktppv2ec7kvtz3v@earth.universe>

Sebastian Reichel <sebastian.reichel@collabora.com> 於 2021年1月16日 週六 下午6:12寫道:
>
> Hi,
>
> On Mon, Jan 11, 2021 at 08:15:33PM +0800, Gene Chen wrote:
> > Sebastian Reichel <sebastian.reichel@collabora.com> 於 2021年1月7日 週四 上午4:16寫道:
> > > > +     last_usb_type = mci->psy_usb_type;
> > > > +     /* Plug in */
> > > > +     ret = regmap_read(mci->regmap, MT6360_PMU_USB_STATUS1, &usb_status);
> > > > +     if (ret < 0)
> > > > +             goto out;
> > > > +     usb_status &= MT6360_USB_STATUS_MASK;
> > > > +     usb_status >>= MT6360_USB_STATUS_SHFT;
> > > > +     switch (usb_status) {
> > > > +     case MT6360_CHG_TYPE_UNDER_GOING:
> > > > +             dev_info(mci->dev, "%s: under going...\n", __func__);
> > > > +             goto out;
> > >
> > > IDK what this is supposed to tell me. Do you mean "detection in
> > > progress"? Also why is this info level? I would expect either
> > > debug (assuming it happens regularly and is normal) or warning
> > > (assuming it should not happen).
> > >
> >
> > When handling attach interrupt and cable plug out at the same
> > time, HW change register status. So we don' need to handle this
> > attach interrupt at this case.
>
> So this is basically for debouncing? I suggest adding a comment:
>
> /* Received attach IRQ followed by detach event, so nothing to do */
> dev_dbg(mci->dev, "under going...\n");
> goto out;
>

Sorry I have a little misunderstand.
under going is "detect in progress".
Attachi irq will trigger when power ready(vbus=5V) and bc12
chargedetection done.
Another irq, Detachi, is indicated power not ready(vbus=0V) and which
is be masked.
So, if the usb status is not SDP/NONSTD/CDP/DCP, the result can be
ignored. (e.q. NO VBUS/Under going/BC12 disabled/Reserved address)

> [...]
>
> > > > +     config.dev = &pdev->dev;
> > > > +     config.regmap = mci->regmap;
> > > > +     mci->otg_rdev = devm_regulator_register(&pdev->dev, &mt6360_otg_rdesc,
> > > > +                                             &config);
> > > > +     if (IS_ERR(mci->otg_rdev))
> > > > +             return PTR_ERR(mci->otg_rdev);
> > > > +
> > > > +     ret = mt6360_sysfs_create_group(mci);
> > > > +     if (ret) {
> > > > +             dev_err(&pdev->dev,
> > > > +                     "%s: Failed to create sysfs attrs\n", __func__);
> > > > +             return ret;
> > > > +     }
> > >
> > > Use charger_cfg.attr_grp to register custom sysfs group for
> > > power-supply devices. Otherwise your code is racy (udev may not pick
> > > up the sysfs attributes). Also custom sysfs attributes need to be
> > > documented in Documentation/ABI/testing/sysfs-class-power-<driver>.
> > >
> > > Looking at the attributes you are planning to expose, I don't think they
> > > are suitable for sysfs anyways. Looks more like a debug interface, which
> > > should go into debugfs instead. But it's hard to tell without any documentation
> > > being provided :)
> >
> > ACK, I will change to charger_cfg.attr_grp.
> > I assumed the charger algorithm thread is in user space, and take
> > control by sysfs node from charger device, like bq24190.c.
> > Should I change to debugfs?
>
> It's hard to tell without knowing more about the attributes
> your are trying to expose. In debugfs we have relaxed ABI rules,
> so it's easier to adopt naming e.t.c. later.
>

I briefly classify the whole attributes. There are either unused, or
can be replaced by POWER_SUPPLY PROPERTY,
so I will remove unuse part.

HIZ = VBUS_IN high impedance mode.
VMIVR = Maximum input voltage regulation. Let input power can provide
at the predetermined voltage level.
(like POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT)
SYSREG = Config system minimum regulation voltage.
OTG_OC = maximum current of battery boost OTG 5V.
ICHG = maximum Charging current. (like
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT)
IEOC = Like POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT
VOREG = Input voltage regulation. (like
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE)
LBP = Low battery protection for battery boost OTG 5V.
VPREC = Pre-charge volatge level. (maybe can add new prop
POWER_SUPPLY_PROP_PRECHARGE_VOLTAGE)
TE = Charge termination enable/disable.
CHG_WDT_EN = Charger Watch dog timer enable/disable.
CHG_WDT = Charger Watch dog timer, 8/40/80/160s.
WT_FC = Fast charge Timer, 4~20hr.
BAT_COMP = Battery IR compensation resistor setting.
VCLAMP = Battery IR compensation maximum voltage clamp.
USBCHGEN = USB charger detection flow enable/disable.
CHG_EN = Battery charging enable/disable.
CHRDET_EXT = VBUS_IN is between VBUS_UV_TH(3.7V) and VBUS_OV_TH(10.5V)

> -- Sebastian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-18  7:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-24  7:48 [PATCH v3 0/2] power: supply: mt6360_charger: add MT6360 charger support Gene Chen
2020-12-24  7:48 ` Gene Chen
2020-12-24  7:48 ` Gene Chen
2020-12-24  7:48 ` [PATCH v3 1/2] dt-bindings: power: Add bindings document for Charger support on MT6360 PMIC Gene Chen
2020-12-24  7:48   ` Gene Chen
2020-12-24  7:48   ` Gene Chen
2020-12-24  7:48 ` [PATCH v3 2/2] power: supply: mt6360_charger: add MT6360 charger support Gene Chen
2020-12-24  7:48   ` Gene Chen
2020-12-24  7:48   ` Gene Chen
2021-01-06 20:16   ` Sebastian Reichel
2021-01-06 20:16     ` Sebastian Reichel
2021-01-06 20:16     ` Sebastian Reichel
2021-01-11 12:15     ` Gene Chen
2021-01-11 12:15       ` Gene Chen
2021-01-11 12:15       ` Gene Chen
2021-01-16 10:12       ` Sebastian Reichel
2021-01-16 10:12         ` Sebastian Reichel
2021-01-16 10:12         ` Sebastian Reichel
2021-01-18  7:58         ` Gene Chen [this message]
2021-01-18  7:58           ` Gene Chen
2021-01-18  7:58           ` Gene Chen
2021-01-12 12:35   ` Matthias Brugger
2021-01-12 12:35     ` Matthias Brugger
2021-01-12 12:35     ` Matthias Brugger

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=CAE+NS34dKX+Zrzp3zzL2-NFvh7FrCUEminVT8jMBDOvS1ZQH9w@mail.gmail.com \
    --to=gene.chen.richtek@gmail.com \
    --cc=Wilma.Wu@mediatek.com \
    --cc=benjamin.chao@mediatek.com \
    --cc=cy_huang@richtek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gene_chen@richtek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=shufan_lee@richtek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.