Re: [Gta04-owner] [PATCH 10/13] twl4030_charger: add software controlled linear charging mode.
On Sat, 14 Nov 2015 19:12:16 +0100
Pavel Machek <pa...@ucw.cz> wrote:
> Hi!
>
> > > > Pavel Machek <pa...@ucw.cz> writes:
> > > > > On Thu 2015-07-30 10:11:24, NeilBrown wrote:
> > > > >>
> > > > >> Add a 'continuous' option for usb charging which enables
> > > > >> the "linear" charging mode of the twl4030.
> > > > >>
> > > > >> Linear charging does a good job with not-so-reliable power sources.
> > > > >> Auto mode does not work well as it switches off when voltage drops
> > > > >> momentarily. Care must be taken not to over-charge.
> > > > >
> > > > > Can you explain how the user can "care not to over-charge"?
> > > >
> > > > The following text reads:
> > > >
> > > > It was used with a bike hub dynamo since a year or so. In that case
> > > > there are automatically charging stops when the cyclist needs a
> > > > break.
> > > >
> > > > so: take a break from cycling occasionally.
> > >
> > > If the charger does not exceed 4.2V, I'd not call it overcharge. (Yes,
> > > some clever
> > > chargers actually let the battery drop below 4.2V when charge is done,
> > > but...)
> > >
> > Yes, that is the case. Perhaps it is not to be called overcharge but
> > it is said that lithium battery charging has to stop if in CV mode the
> > current drops too low. In automatic mode the charger does exactly
> > that.
> > I would not let a battery for days at 4.2V CV.mode although a lot
> > of cheap chargers
>
> Well, I agree that keeping battery at 4.2V constant voltage mode is
> bad, but I'd not call it overcharge. If someone can fix the comment,
> that would be nice.
>
here is my original comment ("on" was replaced by continuous "now"):
twl4030_charger: add software controlled linear charging mode.
adds a sysfs control node to achieve that.
It can be set to
auto: normal automatic charging is enabled (default)
off: charging is off
on: charing is on (software controlled)
CC/CV mode is still automatically done,
but end of charge due to low current not.
Note: If linear charging mode is used there should be some method of
stopping charging automatically. It is not a so time-critical, but
it is the wrong setting for leaving a charger connected for several
days since Lithium batteries should not be kept at 100% for longer
periods. Linear charging does a good job with not so reliable power
sources, since several voltage controlling is then often too
intelligent. It was used with a bike hub dynamo since a year or so. In
that case there are automatically charging stops when the cyclist needs
a break. Signed-off-by: Andreas Kemnade <andr...@kemnade.info>
> > > If the charger _does_ exceed 4.2V, then the battery will explode. Don't
> > > do that. Don't
> > > offer that to the user.
> > >
> > > On a related note... I've just killed USB charger by overloading it. They
> > > are not protected.
> > >
> > > I believe your automatically-pull-max-power really should stick to the
> > > well-known charging
> > > currents (.5A, 1A, 1.7A), at the very minimum.
> > >
> > The main reason for the patch was to prevent switching off charging
> > when Vbus drops low. The reason was not to get out extremely much
> > current out of the charger.
> > The electrical characteristics of a bicycle as a power source are.
> > - the amount of current available changes
> >- 500mA at around 17km/h
> > - you cannot destroy it by electrically overloading
> >
> > If the current is set to e.g. 500mA and that linear charging mode is
> > enabled, the battery gets the maximum current available (upto
> > 500mA) regardless of the speed which is often changing.
>
> Yes... I guess that makes sense for you, but I wonder if we should be
> doing this by default. It seems a lot of cheap chargers can be easily
> destroyed if you overload them.
>
Hmm, I guess the twl4030_charger would not be the only one destroying
such chargers. I have seen such hub dynamo-friendly behaviour on every
device I had connected to it before (an ipaq h2200, openmoko gta02).
I have checked all usb wall plug chargers I have seen and I found none
which has a lower current then 500mA. Only one has 500mA. The rest has
1A or even 2A.
But I think the non-ending cv stuff is a reason enough so that it is not
the default charge method. I use it only at bootup when battery is low
to have some time to fix charging issues manually and when cycling.
Cycling is detected by acceleration values and I get some feedback if
that charge mode is enabled or disabled.
Regards.
Andreas Kemnade
signature.asc
Description: PGP signature
Re: [Gta04-owner] [PATCH 10/13] twl4030_charger: add software controlled linear charging mode.
On Tue, 6 Oct 2015 16:34:07 +0200 Pavel Machek <pa...@ucw.cz> wrote: > Hi! > > > Pavel Machek <pa...@ucw.cz> writes: > > > On Thu 2015-07-30 10:11:24, NeilBrown wrote: > > >> > > >> Add a 'continuous' option for usb charging which enables > > >> the "linear" charging mode of the twl4030. > > >> > > >> Linear charging does a good job with not-so-reliable power sources. > > >> Auto mode does not work well as it switches off when voltage drops > > >> momentarily. Care must be taken not to over-charge. > > > > > > Can you explain how the user can "care not to over-charge"? > > > > The following text reads: > > > > It was used with a bike hub dynamo since a year or so. In that case > > there are automatically charging stops when the cyclist needs a break. > > > > so: take a break from cycling occasionally. > > If the charger does not exceed 4.2V, I'd not call it overcharge. (Yes, some > clever > chargers actually let the battery drop below 4.2V when charge is done, but...) > Yes, that is the case. Perhaps it is not to be called overcharge but it is said that lithium battery charging has to stop if in CV mode the current drops too low. In automatic mode the charger does exactly that. I would not let a battery for days at 4.2V CV.mode although a lot of cheap chargers > If the charger _does_ exceed 4.2V, then the battery will explode. Don't do > that. Don't > offer that to the user. > > On a related note... I've just killed USB charger by overloading it. They are > not protected. > > I believe your automatically-pull-max-power really should stick to the > well-known charging > currents (.5A, 1A, 1.7A), at the very minimum. > The main reason for the patch was to prevent switching off charging when Vbus drops low. The reason was not to get out extremely much current out of the charger. The electrical characteristics of a bicycle as a power source are. - the amount of current available changes - 500mA at around 17km/h - you cannot destroy it by electrically overloading If the current is set to e.g. 500mA and that linear charging mode is enabled, the battery gets the maximum current available (upto 500mA) regardless of the speed which is often changing. Regards, Andreas Kemnade signature.asc Description: PGP signature
Re: receiving data from mcbsp1 in master mode
On Thu, 23 Aug 2012 11:47:59 +0300 Peter Ujfalusi peter.ujfal...@ti.com wrote: On 08/22/2012 11:19 PM, Andreas Kemnade wrote: if I understand the TRM correctly, according to Figure 21-26 in chapter 21.4.2.3. if GSYNC is set, the receiver uses the signal from the sample rate generator, so CLKX does not need to be the CLKR source. But I tried also with the DEVCONF0 MCBSP1_CLKR bit as you proposed. I tried snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0, SND_SOC_CLOCK_OUT); snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0, SND_SOC_CLOCK_OUT); There is an issue with the 6pin mux code, try to add this patch: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/054041.html That is exactly the patch I was talking about in the next line, see http://marc.info/?l=linux-omapm=134540540412165w=2 That is why I send you my patch about that mux settings. But I had no success. ^ The CLKX as CLKR source and FSX as FSR source setting I have only seen when mcbsp1 is used in slave mode. If you know any working code which uses mcbsp1 in master mode then let me know. No, I don't have board which uses McBSP1. -- Péter signature.asc Description: PGP signature
Re: receiving data from mcbsp1 in master mode
Hi, On Tue, 21 Aug 2012 16:42:19 +0300 Peter Ujfalusi peter.ujfal...@ti.com wrote: On 08/21/2012 08:42 AM, Andreas Kemnade wrote: Hi, I tried a couple of times with different kernels to use mcbsp1 of dm3730 in master mode (so that it sends out clocks). The result always is that I can send data out. but arecord gets no input. It waits for input but does not get anything, although clocks are generated, checked that with a scope. I even took a driver which works in master mode on another mcbsp and just changed the mcbsp number. What needs to be done to receive data from mcbsp1? You should check the PIN mux configuration of McBSP1 FSR/CLKR pins. McBSP1 on dm3730 have 6 pin configuration. I think the capture should work fine if you select the FSX as FSR source, and CLKX as CLKR source. if I understand the TRM correctly, according to Figure 21-26 in chapter 21.4.2.3. if GSYNC is set, the receiver uses the signal from the sample rate generator, so CLKX does not need to be the CLKR source. But I tried also with the DEVCONF0 MCBSP1_CLKR bit as you proposed. I tried snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0, SND_SOC_CLOCK_OUT); snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0, SND_SOC_CLOCK_OUT); That is why I send you my patch about that mux settings. But I had no success. The CLKX as CLKR source and FSX as FSR source setting I have only seen when mcbsp1 is used in slave mode. If you know any working code which uses mcbsp1 in master mode then let me know. Greetings Andreas Kemnade signature.asc Description: PGP signature
receiving data from mcbsp1 in master mode
Hi, I tried a couple of times with different kernels to use mcbsp1 of dm3730 in master mode (so that it sends out clocks). The result always is that I can send data out. but arecord gets no input. It waits for input but does not get anything, although clocks are generated, checked that with a scope. I even took a driver which works in master mode on another mcbsp and just changed the mcbsp number. What needs to be done to receive data from mcbsp1? Greetings Andreas Kemnade signature.asc Description: PGP signature
[PATCH] omap-mcbsp: properly check for availablity of mcbsp mux settings
The code did return -EINVAl when the mux_signal function pointer is available.
If not, the corresponding function (the NULL pointer) is called.
This patch inverts that logic.
Signed-off-by: Andreas Kemnade andr...@kemnade.info
---
sound/soc/omap/mcbsp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
index 34835e8..d33c48b 100644
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -745,7 +745,7 @@ int omap_mcbsp_6pin_src_mux(struct omap_mcbsp *mcbsp, u8
mux)
{
const char *signal, *src;
- if (mcbsp-pdata-mux_signal)
+ if (!mcbsp-pdata-mux_signal)
return -EINVAL;
switch (mux) {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
