Re: Nokia N900: u-SD card in v4.2+
Hi! > On Thursday 07 January 2016 02:16 AM, Pavel Machek wrote: > > Hi! > > > > In v4.1, both internal MMC and u-SD cards work ok. > > > > In v4.2, only the internal MMC is detected. In v4.3, not even internal > > MMC works. In v4.4, only the internal MMC is detected. > > > > Does it work for you? Any patches? > > I don't have Nokia N900 to check this, but can you share your config and > kernel > logs? Check if CONFIG_REGULATOR_PBIAS is present in your config. > CONFIG_REGULATOR_PBIAS is now mandatory for all omap3+ SoCs to work. I enabled CONFIG_REGULATOR_PBIAS and both MMCs now work. I wonder if we should add some selects, so that users updating from old kernels don't break their system? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Nokia N900: u-SD card in v4.2+
Hi! In v4.1, both internal MMC and u-SD cards work ok. In v4.2, only the internal MMC is detected. In v4.3, not even internal MMC works. In v4.4, only the internal MMC is detected. Does it work for you? Any patches? (I do have hack in the dts to disable back cover detection...) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH] ARM: dts: omap3: Include missing bandgap data for ti-soc-thermal driver
On Sat 2015-12-26 00:32:25, Pali Rohár wrote: > Driver for omap3 with documentation is there since v4.4-rc1. > > Signed-off-by: Pali Rohár Acked-by: Pavel Machek Tested-by: Pavel Machek Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH] ARM: dts: n900: Include adp1653 device
On Sat 2015-12-26 00:40:12, Pali Rohár wrote: > This patch adds adp1653 device into n900 DT structure. DT support in > adp1653 driver is there since v4.2-rc1 version. > > Signed-off-by: Pali Rohár Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wed 2015-11-11 17:10:46, Frank Rowand wrote: > Adding devicetree list. > > Thread starts at > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html > > On 11/5/2015 8:17 AM, Tony Lindgren wrote: > > * Pali Rohár [151105 03:41]: > >> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote: > >>> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote: > * Pali Rohár [151012 13:29]: > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: > >> > >> Pali, any news on posting an updated series with the comments > >> addressed in this thread? It seems that we all pretty much agree > >> what needs to be done. > > I'm not real happy with the concept of patches 4 and 5 in this series. > My concern is that those two patches are using the FDT as a transport > mechanism for a binary blob (the atags object). Umm. Ok. Do you have alternative proposal that works for everyone? I mean. This discussion was going for quite a long time, and it would be nice to have some solution... patch proposal... something. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [Gta04-owner] [PATCH 10/13] twl4030_charger: add software controlled linear charging mode.
Hi! > > > Pavel Machek 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. > > 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH 10/13] twl4030_charger: add software controlled linear charging mode.
Hi! > Pavel Machek 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...) 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. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH 1/3] ARM: OMAP2+: N900: always enable IBE bit
Hi!
> The kernel's workaround for Errata 430973 consists of a BTAC/BTB
> flush at context switch. This requires the IBE bit being set, which
> should normally be done by the bootloader.
>
> Since the Nokia N900's bootloader is not easily replaceable,
> a pdata quirk enables the IBE bit for the Nokia N900. Until
> e748994f5cc5, the flush at context switch required
> CONFIG_ARM_ERRATA_430973, so the same check has been used
> for setting the IBE bit.
>
> Since all sold N900s are assumed to be affected, the guard
> can be removed now, so that the IBE bit is always set.
Is the qemu affected?
Does qemu have enough secure support not to fail on this?
Best regards,
Pavel
>
> Signed-off-by: Sebastian Reichel
> ---
> arch/arm/mach-omap2/board-rx51.c | 2 --
> arch/arm/mach-omap2/pdata-quirks.c | 11 ++-
> 2 files changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-rx51.c
> b/arch/arm/mach-omap2/board-rx51.c
> index 2d1e5a6..3df01cc 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -108,11 +108,9 @@ static void __init rx51_init(void)
> rx51_peripherals_init();
>
> if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
> -#ifdef CONFIG_ARM_ERRATA_430973
> pr_info("RX-51: Enabling ARM errata 430973 workaround\n");
> /* set IBE to 1 */
> rx51_secure_update_aux_cr(BIT(6), 0);
> -#endif
> }
>
> /* Ensure SDRC pins are mux'd for self-refresh */
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c
> b/arch/arm/mach-omap2/pdata-quirks.c
> index 821171c..0aa438d 100644
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -249,18 +249,11 @@ static void __init nokia_n900_legacy_init(void)
> hsmmc2_internal_input_clk();
>
> if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
> - if (IS_ENABLED(CONFIG_ARM_ERRATA_430973)) {
> - pr_info("RX-51: Enabling ARM errata 430973
> workaround\n");
> - /* set IBE to 1 */
> - rx51_secure_update_aux_cr(BIT(6), 0);
> - } else {
> - pr_warn("RX-51: Not enabling ARM errata 430973
> workaround\n");
> - pr_warn("Thumb binaries may crash randomly without this
> workaround\n");
> - }
> + pr_info("RX-51: Enabling ARM errata 430973 workaround\n");
> + rx51_secure_update_aux_cr(BIT(6), 0); /* set IBE to 1 */
>
> pr_info("RX-51: Registring OMAP3 HWRNG device\n");
> platform_device_register(&omap3_rom_rng_device);
> -
> }
> }
>
> --
> 2.1.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: omapdss: Division by zero in kernel
> > if (image->depth == 1) {
> > if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
> > p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
> > fgcolor =
> > ((u32*)(p->pseudo_palette))[image->fg_color];
> > bgcolor =
> > ((u32*)(p->pseudo_palette))[image->bg_color];
> > } else {
> > fgcolor = image->fg_color;
> > bgcolor = image->bg_color;
> > }
> >
> > if (32 % bpp == 0 && !start_index && !pitch_index &&
> > ((width & (32/bpp-1)) == 0) &&
> > bpp >= 8 && bpp <= 32)
> > fast_imageblit(image, p, dst1, fgcolor, bgcolor);
> > else
> > slow_imageblit(image, p, dst1, fgcolor, bgcolor,
> > start_index, pitch_index);
> > } else
> > color_imageblit(image, p, dst1, start_index, pitch_i
> >
> >
> > Notice that bpp is not checked for zero, and thus bpp==0 is totally
> > feasible? resulting in 32/bpp crashing the kernel?
> >
>
> Hm... this could really be a problem! But how to patch it? Which branch
> should be called (fast_ or slow_ function) if bpp is zero?
>
> And is there some way to force kernel to dump backtrace into dmesg when
> division by zero occur?
You can do WARN_ON(bpp==1) ... and should probably return in that
case.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: [PATCH 04/13] twl4030_charger: trust phy to determine when USB power is available.
On Thu 2015-07-30 10:11:24, NeilBrown wrote: > The usb phy driver already determines when VBUS is available, > so repeating the test in the charger driver is pointless duplication. > > On probe, process the last event from the phy, and from then on, > do whatever the phy tells us without double-checking. > > Signed-off-by: NeilBrown Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH 01/13] twl4030_charger: use runtime_pm to keep usb phy active while charging.
On Thu 2015-07-30 10:11:24, NeilBrown wrote: > The twl4030 usb phy needs to be active while we are using > the USB VBUS as a current source for charging. > In particular, the usb3v1 regulator must be enabled and the > PHY_PWR_PHYPWD bit must be set to keep the phy powered. > > commit ab37813f4093a5f59cb8e083cde277289dc72ed3 > twl4030_charger: Allow charger to control the regulator that feeds it > > gave the charger control over the regulator, but didn't resolve > the PHY_PWR_PHYPWD issue. > > Now that both of these are controlled by runtime_pm in > phy-twl4030-usb, we can simply take a runtime_pm reference to the USB > phy whenever the charger wants to use it as a current source. > > So this patch reverts the above commit, and adds the necessary > runtime_pm calls. > > Acked-by: Lee Jones > Signed-off-by: NeilBrown Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH 10/13] twl4030_charger: add software controlled linear charging mode.
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"?
> @@ -750,6 +784,17 @@ static int twl4030_bci_get_property(struct power_supply
> *psy,
> is_charging = state & TWL4030_MSTATEC_USB;
> else
> is_charging = state & TWL4030_MSTATEC_AC;
> + if (!is_charging) {
> + u8 s;
> + twl4030_bci_read(TWL4030_BCIMDEN, &s);
> + if (psy->desc->type == POWER_SUPPLY_TYPE_USB)
> + is_charging = s & 1;
> + else
> + is_charging = s & 2;
> + if (is_charging)
> + /* A little white lie */
> + state = TWL4030_MSTATEC_QUICK1;
I'm not sure... can't this white lie turn into black smoke?
Like.. normally, when battery is below something (like 3.5V) it must
not be quick-charged (because something is very wrong with it). Are
you just forcing the quick charge here?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: [PATCHv3 1/1] ti-soc-thermal: implement omap3 support
On Wed 2015-09-09 21:58:09, Eduardo Valentin wrote: > From: Pavel Machek > > This adds support for OMAP3 chips to ti-soc-thermal. As requested by > TI people, it is marked unreliable and warning is printed. > > Cc: Zhang Rui > Cc: linux...@vger.kernel.org > Cc: linux-omap@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Pavel Machek > Signed-off-by: Eduardo Valentin > --- > .../devicetree/bindings/thermal/ti_soc_thermal.txt | 7 ++ > drivers/thermal/ti-soc-thermal/Kconfig | 15 +++ > drivers/thermal/ti-soc-thermal/Makefile| 1 + > .../thermal/ti-soc-thermal/omap3-thermal-data.c| 103 > + > drivers/thermal/ti-soc-thermal/ti-bandgap.c| 10 ++ > drivers/thermal/ti-soc-thermal/ti-bandgap.h| 9 ++ > 6 files changed, 145 insertions(+) > create mode 100644 drivers/thermal/ti-soc-thermal/omap3-thermal-data.c > --- > > Just not leave Pavels work behind, I took his patch and amended a couple > of things: > (1) added the omap3 DT example > (2) improved the dev_warn message > (3) improved the code documentation Thanks! Is it on its way to mainline or is there something more to do? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: Nokia N900 - audio TPA6130A2 problems
Hi! > Maybe some power management problem? Something is not always initialized > correctly? > > I remember that there is some problem (maybe in NoLo - Nokia bootloader) > that sometimes chainloaded U-Boot (booted via NoLo) is not able to > initialize mmc chip (all read operation fails). In U-Boot I added some > code to enable some parts in twl4030 regulator and after that mmc is > working always... Could I get some details? Thay code should be moved to kernel, I'd really like mmc to work, no matter how machine was booted. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: n900 in 4.2-rc0: repeating oopses
On Wed 2015-07-01 23:16:21, Tony Lindgren wrote: > * Pavel Machek [150701 06:11]: > > On Wed 2015-07-01 03:34:22, Tony Lindgren wrote: > > > > > > Works for me after enabling the idle timeouts with the following > > > script and blanking the screen and disconnecting USB: > > > > Um. I'm forcing suspend with "echo mem > /sys/power/state" . (It > > worked in 4.1). That should just make it sleep, no autosuspend-related > > trickery... (But yes, I guess I should set up the leds and try > > autosuspend, too.) > > That too works just fine for me with omap2plus_defconfig after > echo enabled > /sys/class/tty/ttyO2/power/wakeup as I have n900 > in my test rack. Going through that. AFAICT, you are not using devicetree on n900? CONFIG_MACH_NOKIA_RX51=y Unfortunately, not having serials, it is tricky to get any output from that cnofiguration, so I don't know what I got wrong... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: n900 in 4.2-rc0: repeating oopses
Hi! > > > So, Pavel can you re-test? Maybe there can be problem with some driver > > > which Tony did not compiled into zImage? Just speculation... > > > > I re-tested with today's git, and it seems to boot. Thanks for help... > > OK good to hear. > > > Now. "echo mem > /sys/power/state" is broken, as in "returns > > immediately in about 50% cases". The messages are > > > > Powerdomain (per_pwrdm) didn't enter target state 1 > > Powerdomain (core_pwerdm) didn't enter target state 1 > > > > Any ideas? Thanks, > > Works for me after enabling the idle timeouts with the following > script and blanking the screen and disconnecting USB: > > Also both keyboard LEDs should start blinking after the idle > timeout with screen blanked and USB disconnected. If not, you > have some module loaded that blocks the deeper idle states. Ok, tried that, I had to do: cd /sys/class/gpio echo 162 > export cd gpio162 echo out > direction echo 1 > value to get the debug lights to work. But I could not get those leds to blink. > modprobe leds-gpio > modprobe ledtrig-default-on Is this actually neccessary/relevant? > echo 255 > /sys/class/backlight/acx565akm/brightness And this? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v2] thermal: consistently use int for temperatures
On Fri 2015-07-24 15:49:41, Guenter Roeck wrote: > On 07/24/2015 03:11 PM, Pavel Machek wrote: > >On Fri 2015-07-24 06:59:26, Guenter Roeck wrote: > >>On 07/23/2015 11:29 PM, Sascha Hauer wrote: > >>>On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote: > >>>>On Tue 2015-07-21 09:21:32, Sascha Hauer wrote: > >>>>>The thermal code uses int, long and unsigned long for temperatures > >>>>>in different places. > >>>>> > >>>>>Using an unsigned type limits the thermal framework to positive > >>>>>temperatures without need. Also several drivers currently will report > >>>>>temperatures near UINT_MAX for temperatures below 0°C. This will probably > >>>>>immediately shut the machine down due to overtemperature if started below > >>>>>0°C. > >>>>> > >>>>>'long' is 64bit on several architectures. This is not needed since > >>>>>INT_MAX °mC > >>>>>is above the melting point of all known materials. > >>>> > >>>>Can we do something like > >>>> > >>>>typedef millicelsius_t int; > >>>> > >>>>...to document the units? > >>> > >>>I am not very fond of typedefs and I am not sure this adds any value. I > >>>could change it when more people ask for it, but I just sent the new > >>>version without this. > >>> > >> > >>I thought we are supposed to not introduce new typedefs anyway. > > > >You are not supposed to typedef struct, but typedef for millicelsius_t > >would be ok. And it is your only chance if you want people to pay > >attention. If you make it int, someone will pass it to long or > >something else.. > > Seems to me that would be just lazyness. The same person might use 'long' > even if millicelsius_t is defined. A typedef doesn't preclude people > from ignoring it. Well, millicelsius_t will tell people that this is temperature, and being "special" type, they'll try to preserve it. (And you could check with sparse if you really wanted). int and long are common enough so that people will not notice... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v2] thermal: consistently use int for temperatures
On Fri 2015-07-24 06:59:26, Guenter Roeck wrote: > On 07/23/2015 11:29 PM, Sascha Hauer wrote: > >On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote: > >>On Tue 2015-07-21 09:21:32, Sascha Hauer wrote: > >>>The thermal code uses int, long and unsigned long for temperatures > >>>in different places. > >>> > >>>Using an unsigned type limits the thermal framework to positive > >>>temperatures without need. Also several drivers currently will report > >>>temperatures near UINT_MAX for temperatures below 0°C. This will probably > >>>immediately shut the machine down due to overtemperature if started below > >>>0°C. > >>> > >>>'long' is 64bit on several architectures. This is not needed since INT_MAX > >>>°mC > >>>is above the melting point of all known materials. > >> > >>Can we do something like > >> > >>typedef millicelsius_t int; > >> > >>...to document the units? > > > >I am not very fond of typedefs and I am not sure this adds any value. I > >could change it when more people ask for it, but I just sent the new > >version without this. > > > > I thought we are supposed to not introduce new typedefs anyway. You are not supposed to typedef struct, but typedef for millicelsius_t would be ok. And it is your only chance if you want people to pay attention. If you make it int, someone will pass it to long or something else.. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: linux 4.2-rc1 broken Nokia N900
On Fri 2015-07-24 16:18:09, Dave Young wrote: > On 07/11/15 at 02:05pm, Pali Rohár wrote: > > Hello, > > > > now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are > > broken and cause kernel oops... > > > > Basically wifi, touchscreen and rtc drivers not working... > > > > Pali, could you tell how do you test mainline kernel on n900? > > I used to use n900 as a usb dbgp gadget with a backport patch to > 2.6.28 so that I can get early debug kernel message from my laptop. > > I tried mainline previously with Fedora arm, text mode works but > no graphics. Is there a way to use maemo UI with mainline kernel? I'm successfully running MATE desktop from Debian. Even modem works with ofono and custom scripts. https://github.com/dderby/debian900 https://wiki.debian.org/n900-wheezy-armhf https://wiki.debian.org/MaemoAndSqueeze (..and tui project on gitlab). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v2] thermal: consistently use int for temperatures
On Tue 2015-07-21 09:21:32, Sascha Hauer wrote: > The thermal code uses int, long and unsigned long for temperatures > in different places. > > Using an unsigned type limits the thermal framework to positive > temperatures without need. Also several drivers currently will report > temperatures near UINT_MAX for temperatures below 0°C. This will probably > immediately shut the machine down due to overtemperature if started below > 0°C. > > 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC > is above the melting point of all known materials. Can we do something like typedef millicelsius_t int; ...to document the units? > Consistently use a plain 'int' for temperatures throughout the thermal code > and > the drivers. This only changes the places in the drivers where the temperature > is passed around as pointer, when drivers internally use another type this is > not changed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: linux 4.2-rc1 broken Nokia N900
On Wed 2015-07-22 04:03:07, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jul 21, 2015 at 07:17:41PM -0500, Michael Welling wrote:
> > On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
> >
> > This code has my head spinning.
> >
> > I found that the errors do not occur when the driver is built into the
> > kernel.
> >
> > I also found that with the patch below the errors go away.
> >
> > Not sure if it is acceptible but see if it fixes things on your side.
> >
> >
> > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> > index cf8b91b..3164d13 100644
> > --- a/drivers/spi/spi.c
> > +++ b/drivers/spi/spi.c
> > @@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
> > if (!spi->max_speed_hz)
> > spi->max_speed_hz = spi->master->max_speed_hz;
> >
> > - spi_set_cs(spi, false);
> > -
> > if (spi->master->setup)
> > status = spi->master->setup(spi);
> >
> > + spi_set_cs(spi, false);
> > +
> > dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max -->
> > %d\n",
> > (int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
> > (spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
>
> mh. maybe a runtime PM issue?
>
> * external abort on non-linefetch: address cannot be accessed,
>since the module's clocks are disabled
> * built-in works, module not: built-in is probably a little bit
>faster (module must not be loaded from filesystem), so that
>the device has not yet been suspended
> * Before 4.2, omap2_mcspi_set_cs() was called in the setup
>routine, which acquired runtime PM
> * In 4.2, omap2_mcspi_set_cs() seems to be called without a
>prior pm_runtime_get_sync()
> * With your workaround, the device has not yet returned to
>suspend after the runtime PM acquisition in setup()
>
> So I suggest trying the following (compile tested only) patch:
Solves problem for me. I had to apply it by patch -l.
Tested-by: Pavel Machek
Pavel
> -- Sebastian
>
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index 5867384..f7d9ffd 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct
> spi_device *spi, int enable)
>
> static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
> {
> + struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
> u32 l;
>
> /* The controller handles the inverted chip selects
> @@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
> bool enable)
> enable = !enable;
>
> if (spi->controller_state) {
> + pm_runtime_get_sync(mcspi->dev);
> +
> l = mcspi_cached_chconf0(spi);
>
> if (enable)
> @@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
> bool enable)
> l |= OMAP2_MCSPI_CHCONF_FORCE;
>
> mcspi_write_chconf0(spi, l);
> +
> + pm_runtime_mark_last_busy(mcspi->dev);
> + pm_runtime_put_autosuspend(mcspi->dev);
> }
> }
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: linux 4.2-rc1 broken Nokia N900
On Mon 2015-07-20 15:46:47, Michael Welling wrote: > On Tue, Jul 14, 2015 at 09:14:12AM +0200, Pali Rohár wrote: > > On Monday 13 July 2015 17:36:07 Michael Welling wrote: > > > On Tue, Jul 14, 2015 at 12:02:44AM +0200, Pali Rohár wrote: > > > > I think nothing special. I just call: > > > > > > > > export ARCH=arm > > > > export CROSS_COMPILE=arm-linux-gnueabi- > > > > make rx51_defconfig > > > > rm -f arch/arm/boot/zImage > > > > make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y > > > > cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > > > > > arch/arm/boot/zImage.new > > > > mv arch/arm/boot/zImage.new arch/arm/boot/zImage > > > > > > > > > > Where are you getting rx51_defconfig from? > > > > > > This does not appear to be in the kernel source any longer. > > > > > > Can you try the above with omap2plus_defconfig? > > > > > > > It is in my linux-n900 repository: https://github.com/pali/linux-n900 > > Repository contains more n900 specific patches but SPI code is unpatched > > > > https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig > > > > Later in week I can try to compile also with omap2plus_defconfig... > > But in my opinion kernel should not crash with different configuration. > > Has any progress been made on this? > > Seeing as I was dropped into the middle of this thread, > I took a look at the discussion previous. > > It appears that you are building the drivers as modules. > Perhaps I can again attempt to duplicate the issue using modules. > Though this should not make a difference. Actually.. for the record I'm _not_ using modules. So either I hit something different, or problem happens regardless of modules. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: linux 4.2-rc1 broken Nokia N900
On Tue 2015-07-21 09:31:27, Pavel Machek wrote: > On Wed 2015-07-15 15:10:48, Michael Welling wrote: > > On Wed, Jul 15, 2015 at 09:49:33PM +0200, Pavel Machek wrote: > > > Hi! > > > > > > > > Ok, so: > > > > > > > > > > 4.2-rc1 worked for me, IIRC. > > > > > > > > This does not make sense. > > > > > > > > Nothing has changed in drivers/spi between these versions. > > > > Are you sure that 4.2-rc1 worked for you? > > > > > > Tested again: yes, I have 4.2-rc1 booted on the device... based on > > > Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the > > > configs and trees to some public place. > > > > > > > Interesting. Something very strange is happening here. > > Send me the links if you push your tree/config to a public repo. > > Pushing now. It is on > kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 mini-v4.2 Actually, pali, if you have time. I pushed kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 n900-v4.2 too, that one should work. (Modulo gsm and s2ram). If you could confirm that, that would be great. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: linux 4.2-rc1 broken Nokia N900
On Wed 2015-07-15 15:10:48, Michael Welling wrote: > On Wed, Jul 15, 2015 at 09:49:33PM +0200, Pavel Machek wrote: > > Hi! > > > > > > Ok, so: > > > > > > > > 4.2-rc1 worked for me, IIRC. > > > > > > This does not make sense. > > > > > > Nothing has changed in drivers/spi between these versions. > > > Are you sure that 4.2-rc1 worked for you? > > > > Tested again: yes, I have 4.2-rc1 booted on the device... based on > > Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the > > configs and trees to some public place. > > > > Interesting. Something very strange is happening here. > Send me the links if you push your tree/config to a public repo. Pushing now. It is on kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 mini-v4.2 f1376b91c1c765cf041235c14ac44c04d56fd2a9 is broken cb8b6850aa49f72f226629796e349dd75d3f4f78 mostly works. (My notes say that GSM is broken, but they may be not enough patches applied.) I believe I even run the "tefone" testsuite, with only s2ram acting funny. https://gitlab.com/tui/tui/tree/master/ofone > I would not hurt to have the same from Pali for comparison. > > > > > 4.2-rc2 oopses a lot. > > > > > > > > 4.2-rc2+ this patch oopses, too. I don't have serial console, so it is > > > > hard to tell if it is the same oops. > > > > But... I'm not sure I'm getting the same oops. > > If the system is still booting, you could tell if the oopses were the > same if your touchscreen and wifi do no work. I'm pretty sure they worked. I'd notice broken touchscreen. (Sorry, I'm a bit busy at the moment). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: linux 4.2-rc1 broken Nokia N900
Hi! > > Ok, so: > > > > 4.2-rc1 worked for me, IIRC. > > This does not make sense. > > Nothing has changed in drivers/spi between these versions. > Are you sure that 4.2-rc1 worked for you? Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place. > > 4.2-rc2 oopses a lot. > > > > 4.2-rc2+ this patch oopses, too. I don't have serial console, so it is > > hard to tell if it is the same oops. But... I'm not sure I'm getting the same oops. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: linux 4.2-rc1 broken Nokia N900
On Tue 2015-07-14 11:33:42, Michael Welling wrote:
> On Tue, Jul 14, 2015 at 09:14:12AM +0200, Pali Rohár wrote:
> > On Monday 13 July 2015 17:36:07 Michael Welling wrote:
> > > On Tue, Jul 14, 2015 at 12:02:44AM +0200, Pali Rohár wrote:
> > > > I think nothing special. I just call:
> > > >
> > > > export ARCH=arm
> > > > export CROSS_COMPILE=arm-linux-gnueabi-
> > > > make rx51_defconfig
> > > > rm -f arch/arm/boot/zImage
> > > > make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y
> > > > cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb >
> > > > arch/arm/boot/zImage.new
> > > > mv arch/arm/boot/zImage.new arch/arm/boot/zImage
> > > >
> > >
> > > Where are you getting rx51_defconfig from?
> > >
> > > This does not appear to be in the kernel source any longer.
> > >
> > > Can you try the above with omap2plus_defconfig?
> > >
> >
> > It is in my linux-n900 repository: https://github.com/pali/linux-n900
> > Repository contains more n900 specific patches but SPI code is unpatched
> >
> > https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig
> >
> > Later in week I can try to compile also with omap2plus_defconfig...
> > But in my opinion kernel should not crash with different configuration.
>
> True.
>
> Could you try the following change to the set_cs function and see if
>it helps.
Ok, so:
4.2-rc1 worked for me, IIRC.
4.2-rc2 oopses a lot.
4.2-rc2+ this patch oopses, too. I don't have serial console, so it is
hard to tell if it is the same oops.
Pavel
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index 5867384..666038b 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -245,16 +245,18 @@ static void omap2_mcspi_set_enable(const struct
> spi_device *spi, int enable)
>
> static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
> {
> + struct omap2_mcspi_cs *cs = spi->controller_state;
> u32 l;
>
> - /* The controller handles the inverted chip selects
> - * using the OMAP2_MCSPI_CHCONF_EPOL bit so revert
> - * the inversion from the core spi_set_cs function.
> - */
> - if (spi->mode & SPI_CS_HIGH)
> - enable = !enable;
> + if (cs) {
> +
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: musb-hdrc: "Vbus off, timeout 1100 msec" message does not belong in sysfs
On Thu 2015-07-09 23:39:22, Pavel Machek wrote: > Hi! > > sysfs should contain one value per file. This one has at least two, > with nice english sentence as a bonus. > > root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# > cat vbus > Vbus off, timeout 1100 msec > > :-(. Plus, documentation for this is nowhere to be seen: pavel@amd:/data/l/linux-n900$ grep -ri musb Documentation/ABI/ pavel@amd:/data/l/linux-n900$ ..which is a shame, because it is not really clear how to use this one: root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# cat mode b_idle root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# echo a_suspend > mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# echo a > mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# echo a_host > mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# echo b_host > mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# echo a_idle > mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# echo b_wait_acon > mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto# Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: rx51-battery.ko incompatiblity: board code vs DT
On Mon 2015-07-06 21:44:22, Pali Rohár wrote: > Hello, > > now I found out that rx51-battery.ko driver register sysnode > /sys/class/power_supply/rx51-battery/ when booting with legacy board > code. But when booting DT kernel it register sysnode with different name > /sys/class/power_supply/n900-battery/ > > Sysfs node for DT kernel comes from Nokia N900 DTS file: > arch/arm/boot/dts/omap3-n900.dts > > I would propose change which change DTS to "rx51-battery" to have it > compatible with naming which is for legacy board code. It is just > because to have compatibility and same naming scheme and also to make > existing programs to work without needing patching them. > > What do you think? Makes sense.. along with _big_ comment in the dts why we are doing this. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: n900 in 4.2-rc0: repeating oopses
On Wed 2015-07-01 03:34:22, Tony Lindgren wrote: > * Pavel Machek [150701 03:02]: > > On Wed 2015-07-01 09:22:55, Pali Rohár wrote: > > > On Tuesday 30 June 2015 23:59:33 Tony Lindgren wrote: > > > > * Pali Rohár [150630 02:55]: > > > > > > > > > > I will try 4.2 at the end of week. > > > > > > > > At least today's 4.1.0-11549-g05a8256 boots just fine on my n900. > > > > > > > > Regards, > > > > > > > > Tony > > > > > > So, Pavel can you re-test? Maybe there can be problem with some driver > > > which Tony did not compiled into zImage? Just speculation... > > > > I re-tested with today's git, and it seems to boot. Thanks for help... > > OK good to hear. Hmm. Tried to toggle brightness on 4.1, and after few changes: root@n900:~# echo 255 > /sys/class/backlight/acx565akm/brightness root@n900:~# echo 120 > /sys/class/backlight/acx565akm/brightness root@n900:~# echo 10 > /sys/class/backlight/acx565akm/brightness root@n900:~# echo 1 > /sys/class/backlight/acx565akm/brightness ^C^C ^Z seems like acx565akm hung :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: n900 in 4.2-rc0: repeating oopses
On Wed 2015-07-01 03:34:22, Tony Lindgren wrote: > * Pavel Machek [150701 03:02]: > > On Wed 2015-07-01 09:22:55, Pali Rohár wrote: > > > On Tuesday 30 June 2015 23:59:33 Tony Lindgren wrote: > > > > * Pali Rohár [150630 02:55]: > > > > > > > > > > I will try 4.2 at the end of week. > > > > > > > > At least today's 4.1.0-11549-g05a8256 boots just fine on my n900. > > > > > > > > Regards, > > > > > > > > Tony > > > > > > So, Pavel can you re-test? Maybe there can be problem with some driver > > > which Tony did not compiled into zImage? Just speculation... > > > > I re-tested with today's git, and it seems to boot. Thanks for help... > > OK good to hear. > > > Now. "echo mem > /sys/power/state" is broken, as in "returns > > immediately in about 50% cases". The messages are > > > > Powerdomain (per_pwrdm) didn't enter target state 1 > > Powerdomain (core_pwerdm) didn't enter target state 1 > > > > Any ideas? Thanks, > > Works for me after enabling the idle timeouts with the following > script and blanking the screen and disconnecting USB: Um. I'm forcing suspend with "echo mem > /sys/power/state" . (It worked in 4.1). That should just make it sleep, no autosuspend-related trickery... (But yes, I guess I should set up the leds and try autosuspend, too.) Regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: n900 in 4.2-rc0: repeating oopses
On Wed 2015-07-01 09:22:55, Pali Rohár wrote: > On Tuesday 30 June 2015 23:59:33 Tony Lindgren wrote: > > * Pali Rohár [150630 02:55]: > > > > > > I will try 4.2 at the end of week. > > > > At least today's 4.1.0-11549-g05a8256 boots just fine on my n900. > > > > Regards, > > > > Tony > > So, Pavel can you re-test? Maybe there can be problem with some driver > which Tony did not compiled into zImage? Just speculation... I re-tested with today's git, and it seems to boot. Thanks for help... Now. "echo mem > /sys/power/state" is broken, as in "returns immediately in about 50% cases". The messages are Powerdomain (per_pwrdm) didn't enter target state 1 Powerdomain (core_pwerdm) didn't enter target state 1 Any ideas? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: n900 in 4.2-rc0: repeating oopses
Hi!
> Just tried booting 4.2-rc0 on n900 (commit
> 4a10a91756ef381bced7b88cfb9232f660b92d93) and it is broken. Previous
> -rc0 version worked. This time, there's some output on console, but
> too fast for me to read.
>
> It seems oopses happen before mounting root. If you have serial
> console, they should be easy to see.
I tried again according to pali's instructions, and it is still
broken the same way. Any other ideas? Does it work for you?
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..ff6f2bf 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -570,6 +570,7 @@
interrupts = <49>;
dmas = <&sdma 69>;
dma-names = "rx";
+ status = "disabled";
};
smartreflex_core: smartreflex@480cb000 {
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
n900 in 4.2-rc0: repeating oopses
Hi! Just tried booting 4.2-rc0 on n900 (commit 4a10a91756ef381bced7b88cfb9232f660b92d93) and it is broken. Previous -rc0 version worked. This time, there's some output on console, but too fast for me to read. It seems oopses happen before mounting root. If you have serial console, they should be easy to see. I tried booting same kernel in qemu, but it seems to work ok there. Any ideas? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
Hi! > By the way, the previous version was busted, this one should compile. > Input: improve parsing OF parameters for touchscreens > > From: Dmitry Torokhov > > When applying touchscreen parameters specified in device tree let's > make > sure we keep whatever setup was done by the driver and not reset the > missing values to zero. > > Reported-by: Pavel Machek > Signed-off-by: Dmitry Torokhov Tested-by: Pavel Machek Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH] Show proper respect for Heinrich Hertz by using the correct unit for frequency
Hi! > The SI unit of frequency is Hertz, named after Heinrich Hertz, and is > given the symbol "Hz" to denote this. "hz" is not the unit of frequency, > and is in fact meaningless. > > Fix arch/arm to correctly use "Hz", thereby acknowledging Heinrich Hertz > contribution to the modern world. > > --- a/arch/arm/mach-ixp4xx/include/mach/platform.h > +++ b/arch/arm/mach-ixp4xx/include/mach/platform.h > @@ -74,7 +74,7 @@ extern unsigned long ixp4xx_exp_bus_size; > /* > * Clock Speed Definitions. > */ > -#define IXP4XX_PERIPHERAL_BUS_CLOCK (66) /* 66Mhzi APB BUS */ > +#define IXP4XX_PERIPHERAL_BUS_CLOCK (66) /* 66MHzi APB BUS */ > #define IXP4XX_UART_XTAL 14745600 > Speaking about meaningless... What is MHzi supposed to mean? ACK for the rest. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
On Tue 2015-06-02 07:37:31, NeilBrown wrote: > On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I > wrote: > > > Hi, > > > > On Thursday 16 April 2015 01:33 PM, NeilBrown wrote: > > > From: NeilBrown > > > > > > The twl4030 phy can measure, with low precision, the > > > resistance-to-ground of the ID pin. > > > > > > Add a function to read the value, and export the result > > > via sysfs. > > > > Little sceptical about adding new sysfs entries. Do you have a good reason > > to > > add this? > > The hardware can report the value, so why not present it to user-space? > > I originally used this with a udev rule which would configure the maximum > current based on the resistance measure - to work with the particular charger > hardware I have. > > More recent patches try to do all of the max-current configuration in the > kernel, so I could live without exporting the value via sysfs if that is a > show-stopper. > > I can't see where the scepticism comes from though. It is a well defined > and cleary documented feature of the hardware. Why not expose it? sysfs interface is supposed to work for different chargers, without userspace noticing. Are these values the ones that are likely to be useful there? > > > + Possible values are: > > > + ground > > > + 102k > > > + 200k > > > + 440k > > > + floating > > > + unknown ...or would it make more sense to export for example numerical ohms, as that's what are other chargers likely to provide? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
On Tue 2015-06-02 16:06:47, Dr. H. Nikolaus Schaller wrote: > Hi, > > Am 02.06.2015 um 15:49 schrieb Kishon Vijay Abraham I : > > > Hi, > > > > On Tuesday 02 June 2015 03:07 AM, NeilBrown wrote: > >> On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I > >> wrote: > >> > >>> Hi, > >>> > >>> On Thursday 16 April 2015 01:33 PM, NeilBrown wrote: > From: NeilBrown > > The twl4030 phy can measure, with low precision, the > resistance-to-ground of the ID pin. > > Add a function to read the value, and export the result > via sysfs. > >>> > >>> Little sceptical about adding new sysfs entries. Do you have a good > >>> reason to > >>> add this? > >> > >> The hardware can report the value, so why not present it to user-space? > >> > >> I originally used this with a udev rule which would configure the maximum > >> current based on the resistance measure - to work with the particular > >> charger > >> hardware I have. > >> > >> More recent patches try to do all of the max-current configuration in the > >> kernel, so I could live without exporting the value via sysfs if that is a > >> show-stopper. > >> > >> I can't see where the scepticism comes from though. It is a well defined > >> and cleary documented feature of the hardware. Why not expose it? Is it well defined enough that it will work on other chargers, too? > > ABI can never be removed or modified later. So should be really careful > > before adding it. > > Is /sys considered ABI? Yes. > User space developers are always reminded not to rely on /sys nodes. No. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
On Mon 2015-06-01 14:32:13, Dmitry Torokhov wrote:
> On Mon, Jun 01, 2015 at 11:22:26PM +0200, Maxime Ripard wrote:
> > Hi Dmitry,
> >
> > On Mon, Jun 01, 2015 at 10:47:30AM -0700, Dmitry Torokhov wrote:
> > > On Mon, Jun 01, 2015 at 05:21:11PM +0200, Pavel Machek wrote:
> > > >
> > > >
> > > > > > > > The 3eea8b5d68c801fec788b411582b803463834752 is just bad.
> > > > > > >
> > > > > > > You were very welcome to review this patch at the time and/or
> > > > > > > suggest
> > > > > > > a fix that pleases everyone.
> > > > > >
> > > > > > You should be the one that should suggest fixes, as you broke it in
> > > > > > the first place. But clearly you don't understand that.
> > > > >
> > > > > You actually never asked for a fix, and went head first calling this
> > > > > patch "bad" and asking for nothing but reverting it.
> > > >
> > > > Date: Fri, 29 May 2015 21:08:16 +0200
> > > > Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re:
> > > > linux-n900
> > > > ...
> > > > Maxime, can you suggest a fix?
> > >
> > > How about we do something like below (it needs a small edt-ft5x06 fixup
> > > that I'll send separately). Not tested.
> > >
> > > Thanks.
> > >
> > > --
> > > Dmitry
> > >
> > >
> > > Input: improve parsing OF parameters for touchscreens
> > >
> > > From: Dmitry Torokhov
> > >
> > > When applying touchscreen parameters specified in device tree let's make
> > > sure we keep whatever setup was done by the driver and not reset the
> > > missing values to zero.
> > >
> > > Reported-by: Pavel Machek
> > > Signed-off-by: Dmitry Torokhov
> > > ---
> > > drivers/input/touchscreen/edt-ft5x06.c |2 -
> > > drivers/input/touchscreen/of_touchscreen.c | 67
> > > ++--
> > > drivers/input/touchscreen/tsc2005.c|2 -
> > > include/linux/input/touchscreen.h |5 +-
> > > 4 files changed, 48 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/input/touchscreen/edt-ft5x06.c
> > > b/drivers/input/touchscreen/edt-ft5x06.c
> > > index 29d179a..394b1de 100644
> > > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > > @@ -1041,7 +1041,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client
> > > *client,
> > >0, tsdata->num_y * 64 - 1, 0, 0);
> > >
> > > if (!pdata)
> > > - touchscreen_parse_of_params(input);
> > > + touchscreen_parse_of_params(input, true);
> > >
> > > error = input_mt_init_slots(input, MAX_SUPPORT_POINTS, INPUT_MT_DIRECT);
> > > if (error) {
> > > diff --git a/drivers/input/touchscreen/of_touchscreen.c
> > > b/drivers/input/touchscreen/of_touchscreen.c
> > > index b82b520..c132624 100644
> > > --- a/drivers/input/touchscreen/of_touchscreen.c
> > > +++ b/drivers/input/touchscreen/of_touchscreen.c
> > > @@ -14,14 +14,22 @@
> > > #include
> > > #include
> > >
> > > -static u32 of_get_optional_u32(struct device_node *np,
> > > -const char *property)
> > > +static bool touchscreen_get_property_u32(struct device_node *np,
> > > + const char *property,
> > > + unsigned int default_value,
> > > + unsigned int *value)
> > > {
> > > u32 val = 0;
> > > + int error;
> > >
> > > - of_property_read_u32(np, property, &val);
> > > + error = of_property_read_u32(np, property, &val);
> > > + if (error) {
> > > + *value = default_value;
> > > + return false;
> > > + }
> > >
> > > - return val;
> > > + *value = val;
> > > + return true;
> >
> > This looks good.
> >
> > However, of_property_read_u32 already does the right thing here by not
> > update val if the property is not found.
>
> I know but it is not documented anywhere (as far as I know) so I'd
> rather not rely on the implementation detail that might change in the
> future. This is not a hot path so extra assignment should not hurt.
Seriously? Submit a patch documenting it, instead of writing strange
code. I bet everyone and their dog relies on it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
On Mon 2015-06-01 10:47:30, Dmitry Torokhov wrote: > On Mon, Jun 01, 2015 at 05:21:11PM +0200, Pavel Machek wrote: > > > > > > > > > > The 3eea8b5d68c801fec788b411582b803463834752 is just bad. > > > > > > > > > > You were very welcome to review this patch at the time and/or suggest > > > > > a fix that pleases everyone. > > > > > > > > You should be the one that should suggest fixes, as you broke it in > > > > the first place. But clearly you don't understand that. > > > > > > You actually never asked for a fix, and went head first calling this > > > patch "bad" and asking for nothing but reverting it. > > > > Date: Fri, 29 May 2015 21:08:16 +0200 > > Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re: > > linux-n900 > > ... > > Maxime, can you suggest a fix? > > How about we do something like below (it needs a small edt-ft5x06 fixup > that I'll send separately). Not tested. + data_present = touchscreen_get_prop_u32(np, "touchscreen-size-x", + input_abs_get_maximum(axis), + &maximum) | + touchscreen_get_prop_u32(np, "touchscreen-fuzz-x", + input_abs_get_fuzz(axis), + &fuzz); + if (data_present) + touchscreen_set_params(dev, axis, maximum, fuzz); Umm. So you are changing behaviour from "whatever was there" to "input_abs_get_maximum"... in n900 case. Is that a good idea for a regression fix this late in release cycle? Maxime's patch should be easy to fix... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
> > > > The 3eea8b5d68c801fec788b411582b803463834752 is just bad.
> > >
> > > You were very welcome to review this patch at the time and/or suggest
> > > a fix that pleases everyone.
> >
> > You should be the one that should suggest fixes, as you broke it in
> > the first place. But clearly you don't understand that.
>
> You actually never asked for a fix, and went head first calling this
> patch "bad" and asking for nothing but reverting it.
Date: Fri, 29 May 2015 21:08:16 +0200
Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re:
linux-n900
...
Maxime, can you suggest a fix?
...
> diff --git a/drivers/input/touchscreen/of_touchscreen.c
> b/drivers/input/touchscreen/of_touchscreen.c
> index b82b5207c78b..7e98c2e443ab 100644
> --- a/drivers/input/touchscreen/of_touchscreen.c
> +++ b/drivers/input/touchscreen/of_touchscreen.c
> @@ -14,10 +14,10 @@
> #include
> #include
>
> -static u32 of_get_optional_u32(struct device_node *np,
> +static int of_get_optional_u32(struct device_node *np,
> const char *property)
> {
> - u32 val = 0;
> + int val = -1;
>
> of_property_read_u32(np, property, &val);
>
> @@ -42,8 +42,12 @@ static void touchscreen_set_params(struct input_dev *dev,
> }
>
> absinfo = &dev->absinfo[axis];
> - absinfo->maximum = max;
> - absinfo->fuzz = fuzz;
> +
> + if (max >= 0)
> + absinfo->maximum = max;
> +
> + if (fuzz >= 0)
> + absinfo->fuzz = fuzz;
> }
>
> /**
> @@ -57,7 +61,7 @@ static void touchscreen_set_params(struct input_dev *dev,
> void touchscreen_parse_of_params(struct input_dev *dev)
> {
> struct device_node *np = dev->dev.parent->of_node;
> - u32 maximum, fuzz;
> + int maximum, fuzz;
>
> input_alloc_absinfo(dev);
> if (!dev->absinfo)
> -- >8 --
>
> That reduces the max size of the screens, but I don't really expect the screen
> size to reach that order of magnitude before a few years...
Umm. Won't you have to update
- if (maximum || fuzz)
+ if (maximum >= 0 || fuzz >= 0)
? Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
Hi! > > But that's not what I'm asking. See a changelog of > > 3eea8b5d68c801fec788b411582b803463834752 and compare it with what it > > actually does. > > > > It is buggy. If fuzz is specified but maximum is not, it overwites > > maximum with zero. > > If maximum is not set, you'll have other issues anyway. But it really > boils down on what the default behaviour should be. It was not broken before commit 3eea8b5d68c801fec788b411582b803463834752. Maximum was set, but after your patch, it is overwritten with zero. > > Plus it introduces new failure "if (!test_bit(axis, dev->absbit))". > > It's not a new failure, it's testing against stupid code. Yes. In a commit marked "cleanup". We call this "undocumented feature". > If an axis is setup in the DT but not registered in the driver, > something is wrong, most probably the DT. Yes, we have fixed the DT, so that bug you introduced will not happen on n900 with updated device tree. > > Plus it fails to distinguish between "value not specified in the dt" > > and "zero is specified in the dt". > > Again, default behaviour. Again, regression from 4.0 kernel, you are not willing to fix. > > The 3eea8b5d68c801fec788b411582b803463834752 is just bad. > > You were very welcome to review this patch at the time and/or suggest > a fix that pleases everyone. You should be the one that should suggest fixes, as you broke it in the first place. But clearly you don't understand that. Dmitry, please revert 3eea8b5d68c801fec788b411582b803463834752 . You'll probably need to revert 0a363a380954e10fece7cd9931b66056eeb07d56 too. Then, Maxime can submit his multitouch patches in a way it does not break existing setups. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
On Mon 2015-06-01 11:49:19, Maxime Ripard wrote: > On Sat, May 30, 2015 at 12:14:30PM +0200, Pavel Machek wrote: > > Well... the driver was not broken... before you did "cleanup" that did > > two functional changes. And yes, the dts should be fixed, but that > > does not make your "cleanup" good. > > Whether it's good or not is arguable, and it really boils down to what > we consider the default value when properties are missing. > > If it's 0, then my code does the right thing. If it's undefined, well, > I'd expect undefined behaviour to change without any notice. It is "whatever was in the structure in the first place", as it was before you patched the code. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
On Fri 2015-05-29 22:03:06, Maxime Ripard wrote: > On Fri, May 29, 2015 at 02:49:55PM -0500, Felipe Balbi wrote: > > Hi, > > > > On Fri, May 29, 2015 at 09:32:11PM +0200, Pavel Machek wrote: > > > Fix dts to match what the Linux kernel expects. This works around > > > touchscreen problems in 4.1 linux on Nokia n900. > > > > > > Signed-off-by: Pavel Machek > > > > > > diff --git > > > a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt > > > b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt > > > index 4b641c7..09089a6 100644 > > > --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt > > > @@ -32,8 +32,8 @@ Example: > > > touchscreen-fuzz-x = <4>; > > > touchscreen-fuzz-y = <7>; > > > touchscreen-fuzz-pressure = <2>; > > > - touchscreen-max-x = <4096>; > > > - touchscreen-max-y = <4096>; > > > + touchscreen-size-x = <4096>; > > > + touchscreen-size-y = <4096>; > > > > IMHO, the older binding needs to be supported as well. It's fine to > > update the DTS for the new binding, but even Documentation says > > touchscreen-max-[xy] and if the driver changed that, the driver should > > be fixed too. Besides, it seems like this has been in tree since v3.16: > > > > $ git describe a38cfebb56898633687ab337fd53710e63a0aedd > > v3.15-rc5-72-ga38cfebb5689 > > > > So, because this has been wrongly documented for so long, we should > > support both bindings. Sure, deprecate touchscreen-max-[xy], but they > > must still be supported, IMO. > > This property has never been anything but a typo in a documentation of > a single driver. > > Feel free to fix that in that driver, but I don't see why the core > code should handle that isolated typo. Well... the driver was not broken... before you did "cleanup" that did two functional changes. And yes, the dts should be fixed, but that does not make your "cleanup" good. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH] Input: of_touchscreen - remove interdependence of max/fuzz values
On Sat 2015-05-30 04:24:34, Sebastian Reichel wrote:
> Commit 3eea8b5d68c8 introduced a dependency between touchscreen-max-*
> and touchscreen-fuzz-*, so that either both must be specified or none
> of them. If only one of them is specified the other value will be
> reset to 0. This commit restores the previous behaviour, that the
> drivers default value will be used for the unspecified value.
>
> Reported-By: Pavel Machek
> Fixes: 3eea8b5d68c8 (Input: of_touchscreen - rework the DT parsing function)
> Signed-off-by: Sebastian Reichel
> ---
> drivers/input/touchscreen/of_touchscreen.c | 25 +++--
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/input/touchscreen/of_touchscreen.c
> b/drivers/input/touchscreen/of_touchscreen.c
> index b82b520..7d2cf59 100644
> --- a/drivers/input/touchscreen/of_touchscreen.c
> +++ b/drivers/input/touchscreen/of_touchscreen.c
> @@ -42,8 +42,11 @@ static void touchscreen_set_params(struct input_dev *dev,
> }
>
> absinfo = &dev->absinfo[axis];
> - absinfo->maximum = max;
> - absinfo->fuzz = fuzz;
> +
> + if (max)
> + absinfo->maximum = max;
> + if (fuzz)
> + absinfo->fuzz = fuzz;
If driver sets absinfo->fuzz to 5, and then device tree specifies fuzz
of 0, this means it will not be overwritten.
> @@ -65,23 +68,17 @@ void touchscreen_parse_of_params(struct input_dev *dev)
>
> maximum = of_get_optional_u32(np, "touchscreen-size-x");
> fuzz = of_get_optional_u32(np, "touchscreen-fuzz-x");
> - if (maximum || fuzz) {
> - touchscreen_set_params(dev, ABS_X, maximum, fuzz);
> - touchscreen_set_params(dev, ABS_MT_POSITION_X, maximum, fuzz);
> - }
> + touchscreen_set_params(dev, ABS_X, maximum, fuzz);
> + touchscreen_set_params(dev, ABS_MT_POSITION_X, maximum, fuzz);
This will introduce warn_on() on axis that are not mentioned in the
device tree. Same problem Dmitry did not like on my patch.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
On Fri 2015-05-29 13:48:47, Dmitry Torokhov wrote: > On Fri, May 29, 2015 at 10:34:56PM +0200, Pavel Machek wrote: > > Hi! > > > > > > > single DT, you don't even use that property in your driver, and now > > > > > that you realise you meant something else, you want the code that > > > > > > > > not Pali, Sebastian. > > > > > > > > > actually parse the *right* property and does the right thing, that all > > > > > other DT agree (and depend on) to be reverted? > > > > > > > > We shouldn't revert, that I agree. But both properties should be parsed. > > > > > > No. If the property is wrong, and nobody parsed it, I do not see any > > > reason to > > > start now. > > > > Agreed. > > > > But that's not what I'm asking. See a changelog of > > 3eea8b5d68c801fec788b411582b803463834752 and compare it with what it > > actually does. > > > > It is buggy. If fuzz is specified but maximum is not, it overwites > > maximum with zero. > > Yes. > > > > > Plus it introduces new failure "if (!test_bit(axis, dev->absbit))". > > That is not a new failure. It actually warns users that they trying to > specify in DT something that will be ignored by the kernel (because > without that absbit kernel will ignore all requests to that event code). What if driver sets the bits after parsing device tree? > > Plus it fails to distinguish between "value not specified in the dt" > > and "zero is specified in the dt". > > Yes. I am not sure if we should care and support all permutations (ah, I > pre-setup fuzz in the driver, but override max on X, and I pre-setup > max on X, but take fuzz from DT). Maybe we should simply document that > specifying one parameter for an axis will change the rest of them to be > 0. Not sure though... Well, the old code did support all permutations. "cleanups" should not change such details... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
Hi! > > > single DT, you don't even use that property in your driver, and now > > > that you realise you meant something else, you want the code that > > > > not Pali, Sebastian. > > > > > actually parse the *right* property and does the right thing, that all > > > other DT agree (and depend on) to be reverted? > > > > We shouldn't revert, that I agree. But both properties should be parsed. > > No. If the property is wrong, and nobody parsed it, I do not see any reason to > start now. Agreed. But that's not what I'm asking. See a changelog of 3eea8b5d68c801fec788b411582b803463834752 and compare it with what it actually does. It is buggy. If fuzz is specified but maximum is not, it overwites maximum with zero. Plus it introduces new failure "if (!test_bit(axis, dev->absbit))". Plus it fails to distinguish between "value not specified in the dt" and "zero is specified in the dt". The 3eea8b5d68c801fec788b411582b803463834752 is just bad. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
> > > So, because this has been wrongly documented for so long, we should > > > support both bindings. Sure, deprecate touchscreen-max-[xy], but they > > > must still be supported, IMO. > > > > This property has never been anything but a typo in a documentation of > > a single driver. > > > > Feel free to fix that in that driver, but I don't see why the core > > code should handle that isolated typo. > > OK thanks for confirming. Will apply this into omap-for-v4.1/fixes. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
On Fri 2015-05-29 14:49:55, Felipe Balbi wrote: > Hi, > > On Fri, May 29, 2015 at 09:32:11PM +0200, Pavel Machek wrote: > > Fix dts to match what the Linux kernel expects. This works around > > touchscreen problems in 4.1 linux on Nokia n900. > > > > Signed-off-by: Pavel Machek > > > > diff --git > > a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt > > b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt > > index 4b641c7..09089a6 100644 > > --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt > > +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt > > @@ -32,8 +32,8 @@ Example: > > touchscreen-fuzz-x = <4>; > > touchscreen-fuzz-y = <7>; > > touchscreen-fuzz-pressure = <2>; > > - touchscreen-max-x = <4096>; > > - touchscreen-max-y = <4096>; > > + touchscreen-size-x = <4096>; > > + touchscreen-size-y = <4096>; > > IMHO, the older binding needs to be supported as well. It's fine to > update the DTS for the new binding, but even Documentation says > touchscreen-max-[xy] and if the driver changed that, the driver should > be fixed too. Besides, it seems like this has been in tree since > v3.16: Agreed. In parent email, I have list of two commits that should be reverted. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
[PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
Fix dts to match what the Linux kernel expects. This works around touchscreen problems in 4.1 linux on Nokia n900. Signed-off-by: Pavel Machek diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt index 4b641c7..09089a6 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt @@ -32,8 +32,8 @@ Example: touchscreen-fuzz-x = <4>; touchscreen-fuzz-y = <7>; touchscreen-fuzz-pressure = <2>; - touchscreen-max-x = <4096>; - touchscreen-max-y = <4096>; + touchscreen-size-x = <4096>; + touchscreen-size-y = <4096>; touchscreen-max-pressure = <2048>; ti,x-plate-ohms = <280>; diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index 5c16145..5f5e0f3 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -832,8 +832,8 @@ touchscreen-fuzz-x = <4>; touchscreen-fuzz-y = <7>; touchscreen-fuzz-pressure = <2>; - touchscreen-max-x = <4096>; - touchscreen-max-y = <4096>; + touchscreen-size-x = <4096>; + touchscreen-size-y = <4096>; touchscreen-max-pressure = <2048>; ti,x-plate-ohms = <280>; -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: n900 in 4.1-rc0
Hi! > > Just tried booting 4.1-rc0 on n900 (commit > > 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085) and it is broken. > > > > Any ideas? > > Looks like DT and legacy booting are working fine in our > labs. [0][1] Interesting web pages, thanks. I noticed that legacy booting indicates broken today, but... Is there list of your targets somewhere? Best regards, Pavel > [0] http://kernelci.org/boot/omap3-n900/ > [1] http://kernelci.org/boot/omap3-n900,legacy/ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: n900 in 4.1-rc0
On Thu 2015-04-16 09:35:54, Tony Lindgren wrote: > * Marc Zyngier [150416 02:38]: > > On 16/04/15 10:32, Pavel Machek wrote: > > > Hi! > > > > > > Just tried booting 4.1-rc0 on n900 (commit > > > 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085) and it is broken. > > > > > > Any ideas? > > > > To such a question, the only answer I have is "Yes". > > > > For a more useful reply, I'm afraid you'll have to ask a better question. > > Just tried it at 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085 > and it boots just fine on my n900. Thanks for testing. I did some investigation, and found that twl4030 charger (that is not useful on n900) was breaking my boot. (And it may be interaction with some of my local changes). Best regards (and sorry for the noise), Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: twl4030_charger: need changes to get probed?
Hi! > >> Ok, but: > >> > >> 1) Why is the twl4030-bci enabled in n900's dts, then > >> > > > > maybe it is bug in n900 dts... > > > > Grazvydas, is there some runtime check if twl4030/twl5030 chip > > has charger or not? or do we need to explicitly disable device > > twl4030-bci in DT? > > Actually from looking at the schematics, it looks like the charger > pins are still there but all connected to ground. So it probably has > the charger after all, it's just not connected or used. > > I'm not aware or any registers for direct detection, and indirect > detection is difficult because BCI mostly disables itself when no > charger is connected and most registers read as 0 or have old values > from last charging session (which will never happen on n900). > > There is IDCODE register on twl4030 itself, but it's documented as not > meaningful when accessed over i2c (when is it meaningful then??). > > drivers/mfd/twl-core.c has a i2c_device_id table of various twl4030 > variants, some of which have no charger. N900 has GAIA/twl5030, which > differs from twl4030 only by vaux2 regulator according to that file. > N900's old board files specify 5030, but .dts does not. I have enabled the (not-too-useful) twl4030 charger on my n900, and it seems to break boot with kernels 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085 and newer. I'll probably not have time to investigate it further (charger not connected to anything is not too useful), but maybe Neil wants to test on his phone...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH 4/6] phy: twl4030-usb: add ABI documentation
On Thu 2015-04-16 18:03:04, NeilBrown wrote: > From: NeilBrown > > This driver device one local attribute: vbus. > Describe that in Documentation/ABI/testing/sysfs-platform/twl4030-usb. > > Signed-off-by: NeilBrown > --- > .../ABI/testing/sysfs-platform-twl4030-usb |8 > 1 file changed, 8 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-platform-twl4030-usb > > diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb > b/Documentation/ABI/testing/sysfs-platform-twl4030-usb > new file mode 100644 > index ..512c51be64ae > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb > @@ -0,0 +1,8 @@ > +What: /sys/bus/platform/devices/*twl4030-usb/vbus > +Description: > + Read-only status reporting if VBUS (approx 5V) > + is being supplied by the USB bus. > + > + Possible values: "on", "off". Would bit be better to have values "0" and "1"? Kernel usually does that for booleans... Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
n900 in 4.1-rc0
Hi! Just tried booting 4.1-rc0 on n900 (commit 34c9a0ffc75ad25b6a60f61e27c4a4b1189b8085) and it is broken. Any ideas? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv7] media: i2c/adp1653: Devicetree support for adp1653
Hi! > > #define to_adp1653_flash(sd) container_of(sd, struct adp1653_flash, > > subdev) > > > > Let me know if you're going to send v8 or if I can make the changes. I think > we're pretty much done then. You are free to make the changes. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
[PATCHv7] media: i2c/adp1653: fix includes
Fix includes according to Sebastian. Signed-off-by: Pavel Machek --- On Thu 2015-04-09 14:19:14, Sebastian Reichel wrote: > On Thu, Apr 09, 2015 at 01:29:43PM +0200, Pavel Machek wrote: > > On Thu 2015-04-09 11:10:17, Sebastian Reichel wrote: > > > On Thu, Apr 09, 2015 at 09:42:38AM +0200, Pavel Machek wrote: > > > > [...] > > > > +#include > > > > +#include > > > > [...] > > > > > > This should probably be > > > > > > #include > > > #include > > > > And I thought people would only bikesched paint on the > > Documentation. Sakari, feel free to change that, but > > > a) I don't see why Sebastian's version is better > > You neither use nor . > > Well "include/linux/gpio.h" describes the old gpio API. The new > gpiod gpiod API is described in "include/linux/gpio/consumer.h" and > you use it, so the include should be included ;) > > You don't use anything from "include/linux/of_gpio.h", but it > includes "include/linux/of.h", which you are using. So you should > include instead ;) diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c index d703636..7107ac2 100644 --- a/drivers/media/i2c/adp1653.c +++ b/drivers/media/i2c/adp1653.c @@ -35,8 +35,8 @@ #include #include #include -#include -#include +#include +#include #include #include -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv7] media: i2c/adp1653: Devicetree support for adp1653
On Thu 2015-04-09 11:10:17, Sebastian Reichel wrote: > Hi, > > On Thu, Apr 09, 2015 at 09:42:38AM +0200, Pavel Machek wrote: > > [...] > > +#include > > +#include > > [...] > > This should probably be > > #include > #include And I thought people would only bikesched paint on the Documentation. Sakari, feel free to change that, but a) I don't see why Sebastian's version is better and b) am pretty sure there is about infinite number of possibilities there. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
[PATCHv7] media: i2c/adp1653: Devicetree support for adp1653
Add device tree support for adp1653 flash LED driver.
Signed-off-by: Pavel Machek
---
Second part of a patch after documentation was merged.
Please apply,
Pavel
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index 873fe19..d703636 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -8,6 +8,7 @@
* Contributors:
* Sakari Ailus
* Tuukka Toivonen
+ * Pavel Machek
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -34,6 +35,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -306,9 +309,17 @@ adp1653_init_device(struct adp1653_flash *flash)
static int
__adp1653_set_power(struct adp1653_flash *flash, int on)
{
- int ret;
+ int ret = 0;
+
+ if (flash->platform_data->power) {
+ ret = flash->platform_data->power(&flash->subdev, on);
+ } else {
+ gpiod_set_value(flash->platform_data->enable_gpio, on);
+ if (on)
+ /* Some delay is apparently required. */
+ udelay(20);
+ }
- ret = flash->platform_data->power(&flash->subdev, on);
if (ret < 0)
return ret;
@@ -316,8 +327,13 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
return 0;
ret = adp1653_init_device(flash);
- if (ret < 0)
+ if (ret >= 0)
+ return ret;
+
+ if (flash->platform_data->power)
flash->platform_data->power(&flash->subdev, 0);
+ else
+ gpiod_set_value(flash->platform_data->enable_gpio, 0);
return ret;
}
@@ -407,21 +423,78 @@ static int adp1653_resume(struct device *dev)
#endif /* CONFIG_PM */
+static int adp1653_of_init(struct i2c_client *client,
+ struct adp1653_flash *flash,
+ struct device_node *node)
+{
+ u32 val;
+ struct adp1653_platform_data *pd;
+ struct device_node *child = NULL;
+
+ if (!node)
+ return -EINVAL;
+
+ pd = devm_kzalloc(&client->dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+ flash->platform_data = pd;
+
+ child = of_get_child_by_name(node, "flash");
+ if (!child)
+ return -EINVAL;
+
+ if (of_property_read_u32(child, "flash-timeout-us", &val))
+ goto err;
+
+ pd->max_flash_timeout = val;
+ if (of_property_read_u32(child, "flash-max-microamp", &val))
+ goto err;
+ pd->max_flash_intensity = val/1000;
+
+ if (of_property_read_u32(child, "max-microamp", &val))
+ goto err;
+ pd->max_torch_intensity = val/1000;
+ of_node_put(child);
+
+ child = of_get_child_by_name(node, "indicator");
+ if (!child)
+ return -EINVAL;
+ if (of_property_read_u32(child, "max-microamp", &val))
+ goto err;
+ pd->max_indicator_intensity = val;
+
+ of_node_put(child);
+
+ pd->enable_gpio = devm_gpiod_get(&client->dev, "enable");
+ if (!pd->enable_gpio) {
+ dev_err(&client->dev, "Error getting GPIO\n");
+ return -EINVAL;
+ }
+
+ return 0;
+err:
+ dev_err(&client->dev, "Required property not found\n");
+ of_node_put(child);
+ return -EINVAL;
+}
+
+
static int adp1653_probe(struct i2c_client *client,
const struct i2c_device_id *devid)
{
struct adp1653_flash *flash;
int ret;
- /* we couldn't work without platform data */
- if (client->dev.platform_data == NULL)
- return -ENODEV;
-
flash = devm_kzalloc(&client->dev, sizeof(*flash), GFP_KERNEL);
if (flash == NULL)
return -ENOMEM;
flash->platform_data = client->dev.platform_data;
+ if (client->dev.of_node) {
+ ret = adp1653_of_init(client, flash, client->dev.of_node);
+ if (ret)
+ return ret;
+ }
mutex_init(&flash->power_lock);
@@ -442,6 +515,7 @@ static int adp1653_probe(struct i2c_client *client,
return 0;
free_and_quit:
+ dev_err(&client->dev, "adp1653: failed to register device\n");
v4l2_ctrl_handler_free(&flash->ctrls);
return ret;
}
@@ -464,7 +538,7 @@ static const struct i2c_device_id adp1653_id_table[] = {
};
MODULE_DEVICE_TABLE(i2c, adp1653_id_table);
-static struct dev_pm_ops adp1653_pm_ops = {
+static const struct dev_
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Hi! > enable-gpios: Specifier of the GPIO connected to EN pin > > I can make the changes if you're ok with that, otherwise please send v7. Then > I'll apply that to my tree. I'm ok with that. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi! > >> Please propose your own code doing that so that we can test if it is > >> better. > > > > So, how does this look? > > > > It looks to me like you have cca 0.1 Ohm resistance in your system, > > This is completely unknown. > > > and are using cca 75mA while discharging, and charge by cca 1.4A. > > Where do you get these figures from? Least squares fitting of my coefficients to your tables. > A GTA04 board discharges usually between 50 and 400 mA (depending on > activities) > and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw > even more > during operation. How big battery do you have? According to least squares fitting, assuming maximum charge of .46A, you were taking about 25mA when doing the discharge test. > Total current going in is 500-800 mA (depending on USB negotiations) and this > is > split into system operation and charging current. So 1.4A charging current is > not > possible. Rather 200-500 mA. > > So it might be that the battery is discharged although the system is connected > to a charger. Yah, and your battery meter will be wrong in such case, as will be mine, because they are based on same information. The thing is, mine can be improved without adding more tables. > > It is tricky to do a good job near 0%... or anywhere else. See for > > example > > > > http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf > > > > You start a call, percentage goes down, end a call, it will go > > back up. I'm pretty sure you will not be able to make a call with "5%" > > indication from your code at low battery temperature (say -10C). > > The whole system is heating up a little, so that you never have -10C for the > battery. Umm. When not calling, your phone should not heat itself up. And you definitely can power it down, leave it in outer pocket, then power it up. It is actually something people do when they want to preserve battery... > I think you are trying to solve situations that don’t exist in practice. > > And AFAIK, the GTA04 board is the only user of this driver in case the battery > has no built-in fuel gauge. So why improve it beyond what the GTA04 > users need? Because then other users can share the same code, and because you avoid big ugly tables in dts. > I repeat myself: this driver is not built for highest precision because there > are > better methods (fuel gauge chip). These might not be available so this > fall-back > driver has been built. > > It is definitively better than no driver and worse than the optimum. And my email suggested solution better than your driver, so why not just use it? > > #perc = percent(volt) > > compute(charging, 1) > > compute(discharging, 0) > > Please explain what you calculate here. Especially what “Badness” is? Badness is error in least squares method. Here are updated tables: pavel@duo:~/g/tui/ofone$ ./liion_maps Charging Voltage 4.2 V ; table 100 % internal voltage 4.18 V current 0.078 A computed 97 % Voltage 4.1 V ; table 75 % internal voltage 4.08 V current 0.078 A computed 87 % Voltage 4.0 V ; table 55 % internal voltage 3.93 V current 0.233 A computed 69 % Voltage 3.9 V ; table 25 % internal voltage 3.76 V current 0.467 A computed 26 % Voltage 3.8 V ; table 5 % internal voltage 3.66 V current 0.467 A computed 3 % Voltage 3.7 V ; table 2 % internal voltage 3.56 V current 0.467 A computed 2 % Voltage 3.6 V ; table 1 % internal voltage 3.46 V current 0.467 A computed 1 % Voltage 3.3 V ; table 0 % internal voltage 3.16 V current 0.467 A computed -1 % Badness 395.4861761427434 Discharging Voltage 4.2 V ; table 100 % internal voltage 4.21 V current -0.025 A computed 100 % Voltage 4.1 V ; table 95 % internal voltage 4.11 V current -0.025 A computed 91 % Voltage 4.0 V ; table 70 % internal voltage 4.01 V current -0.025 A computed 79 % Voltage 3.8 V ; table 50 % internal voltage 3.81 V current -0.025 A computed 46 % Voltage 3.7 V ; table 10 % internal voltage 3.71 V current -0.025 A computed 3 % Voltage 3.6 V ; table 5 % internal voltage 3.61 V current -0.025 A computed 2 % Voltage 3.3 V ; table 0 % internal voltage 3.31 V current -0.025 A computed 0 % Badness 171.69576218433212 pavel@duo:~/g/tui/ofone$ python Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH 13/14] twl4030_charger: Increase current carefully while watching voltage.
Hi! > > > The USB Battery Charging spec (BC1.2) suggests a dedicated > > > charging port can deliver from 0.5 to 5.0A at between 4.75 and 5.25 > > > volts. > > > > > > To choose the "correct" current voltage setting requires a trial > > > and error approach: try to draw current and see if the voltage drops > > > too low. > > > > > > Even with a configured Standard Downstream Port, it may not be possible > > > to reliably pull 500mA - depending on cable quality and source > > > quality I have reports of charging failure due to the voltage dropping > > > too low. > > > > > > To address both these concerns, this patch introduce incremental > > > current setting. > > > The current pull from VBUS is increased in steps of 20mA every 100ms > > > until the target is reached or until the measure voltage drops below > > > 4.75V. If the voltage does go too low, the target current is reduced > > > by 20mA and kept there. > > > > Still nervous. If it is possible to overheat the charger, without > > tripping internal fuse, then you'll do it. > > If it is possible to overheat the charger without tripping an internal fuse, > then sure the charger is mis-designed - is it not? > > Can you suggest an algorithm for determining how much current can safely be > pulled from a charger that would *not* make you nervous? Not nervous? No. Less nervous? Run detection as you do, but then round down to "known reasonable" max charging currents? If you detected 1.1A charger, you are probably overloading 1A charger. So idea would be to round down to 0.5A, 1A, 1.7A. > > Idle device. Code will find that it can charge using 1A, backs up to > > 0.9A. User starts hotspot. Now device will draw 1.4A, overloading the > > charger and not charging at all...? > > The current being measured and controlled is the current flowing in from the > USB VBUS, not flowing out to the battery. > So I the code choose 0.9A, that is all that will be drawn. > > This is a possible issue similar to this though. > If the device is idle and the battery is fully charged, then it won't draw > much current from USB even if we allow it too. > So the algorithm might decide it is OK to draw 1.7A because at that time the > device cannot use more than 200mA, and that doesn't cause the voltage to drop. > > Then later when user enabled wifi-hotspot, the current needed might go up > above what the charger can provide. > > Maybe I should only increase the limit while the actual current is also > increasing. Maybe also revisit the setting when the battery starts charging. Yes, that sounds better. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Documentation for adp1653 binding.
Signed-off-by: Pavel Machek
---
Please apply.
Sorry, wrong version of patch was sent last time.
Pavel
diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
new file mode 100644
index 000..4607ce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -0,0 +1,37 @@
+* Analog Devices ADP1653 flash LED driver
+
+Required Properties:
+
+ - compatible: Must contain be "adi,adp1653"
+
+ - reg: I2C slave address
+
+ - enable-gpios: Reference to the GPIO that controls the power for the chip.
+
+There are two LED outputs available - flash and indicator. One LED is
+represented by one child node, nodes need to be named "flash" and "indicator".
+
+Required properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+
+Required properties of the flash LED child node:
+
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+ adp1653: led-controller@30 {
+ compatible = "adi,adp1653";
+ reg = <0x30>;
+ enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+ flash {
+ flash-timeout-us = <50>;
+ flash-max-microamp = <32>;
+ max-microamp = <5>;
+ };
+ indicator {
+ max-microamp = <17500>;
+ };
+ };
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: [PATCHv5] media: i2c/adp1653: devicetree support for adp1653
Hi! > > + pd->max_flash_intensity = val/1000; > > + > > + if (of_property_read_u32(child, "max-microamp", &val)) > > + return -EINVAL; > > + pd->max_torch_intensity = val/1000; > > I think you need to do of_node_put(child) here and after you're done with > indicator below. ...and in most of the error paths. Ok. Will submit the updated patch when the documentation one is accepted. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: ARM errata 430973 on multi platform kernels (was: OMAP3-N900: Add microphone bias voltages)
Hi! > Maybe an option would be to provide two cpu_v7_switch_mm > implementations (one with the errata and one without). Then > the system can start with the simple implementation. Once > the boot as progressed far enough to know, that the hardware > is affected by the errata, it could switch to the implementation > with the flushing. Actually... we should start with the slow&safe option, and then switch to faster implementation if workaround is not needed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653
On Fri 2015-04-03 14:23:56, Sakari Ailus wrote: > Hi Pavel, > > On Fri, Apr 03, 2015 at 10:23:44AM +0200, Pavel Machek wrote: > > Hi! > > > > > Hi Pawel, > > > > I'm still Pavel. v, not w. > > I know too many Pawels. Sorry about that. :-) > > > I guess it uses adp1653_id_table. I'd hade to add redundand > > information, because if it would just mask the errors if the code > > changed... > > Indeed, that's true. This is comparing "adp1653" vs. comparing > "adi,adp1653". I think I still prefer the latter since it's got also the > vendor prefix included. > > Suppose we change this later and someone misspelled the vendor prefix --- > their board would break. Suppose we do what you suggest. That does not fix the problem, since code will still match the "adp1653" in case someone misspells it. If you want to change how i2c device matching works, well, you can do it, but my patch is not right place to do that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
[PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Documentation for adp1653 binding.
---
> Please split this as Javier suggested. I'd think both could go through
> the media-tree unless someone objects.
Please apply.
> > + - power-gpios: Reference to the GPIO that controls the power for the
> > chip.
>
> You're using power-gpios in documentation only.
Which is ok, because generic code adds "-gpios" itself.
> The spec refers to this by "EN". How about "en-gpios" instead? This
> definitely isn't about power, but about resetting the chip. It gets the
> power through another pin.
It controls power of the chip. Noone gets _power_ through gpios,
hopefully. Yes, I can rename it. "en-gpios" is too ugly to
live. Sebastian suggested "enable". Hope that's okay with you.
Pavel
new file mode 100644
index 000..da9934a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -0,0 +1,37 @@
+* Analog Devices ADP1653 flash LED driver
+
+Required Properties:
+
+ - compatible: Must contain be "adi,adp1653"
+
+ - reg: I2C slave address
+
+ - power-gpios: Reference to the GPIO that controls the power for the chip.
+
+There are two LED outputs available - flash and indicator. One LED is
+represented by one child node, nodes need to be named "flash" and "indicator".
+
+Required properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+
+Required properties of the flash LED child node:
+
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+ adp1653: led-controller@30 {
+ compatible = "adi,adp1653";
+ reg = <0x30>;
+ power-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+ flash {
+ flash-timeout-us = <50>;
+ flash-max-microamp = <32>;
+ max-microamp = <5>;
+ };
+ indicator {
+ max-microamp = <17500>;
+ };
+ };
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
[PATCHv5] media: i2c/adp1653: devicetree support for adp1653
We are moving to device tree support on OMAP3, but that currently
breaks ADP1653 driver. This adds device tree support, plus required
documentation.
Signed-off-by: Pavel Machek
---
Switched to gpiod_, as requested by Javier.
Please apply,
Pavel
diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
new file mode 100644
index 000..da9934a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -0,0 +1,37 @@
+* Analog Devices ADP1653 flash LED driver
+
+Required Properties:
+
+ - compatible: Must contain be "adi,adp1653"
+
+ - reg: I2C slave address
+
+ - power-gpios: Reference to the GPIO that controls the power for the chip.
+
+There are two LED outputs available - flash and indicator. One LED is
+represented by one child node, nodes need to be named "flash" and "indicator".
+
+Required properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+
+Required properties of the flash LED child node:
+
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+ adp1653: led-controller@30 {
+ compatible = "adi,adp1653";
+ reg = <0x30>;
+ power-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+ flash {
+ flash-timeout-us = <50>;
+ flash-max-microamp = <32>;
+ max-microamp = <5>;
+ };
+ indicator {
+ max-microamp = <17500>;
+ };
+ };
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index 873fe19..ba7f43d 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -8,6 +8,7 @@
* Contributors:
* Sakari Ailus
* Tuukka Toivonen
+ * Pavel Machek
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -34,6 +35,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -306,9 +309,17 @@ adp1653_init_device(struct adp1653_flash *flash)
static int
__adp1653_set_power(struct adp1653_flash *flash, int on)
{
- int ret;
+ int ret = 0;
+
+ if (flash->platform_data->power) {
+ ret = flash->platform_data->power(&flash->subdev, on);
+ } else {
+ gpiod_set_value(flash->platform_data->power_gpio, on);
+ if (on)
+ /* Some delay is apparently required. */
+ udelay(20);
+ }
- ret = flash->platform_data->power(&flash->subdev, on);
if (ret < 0)
return ret;
@@ -316,8 +327,13 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
return 0;
ret = adp1653_init_device(flash);
- if (ret < 0)
+ if (ret >= 0)
+ return ret;
+
+ if (flash->platform_data->power)
flash->platform_data->power(&flash->subdev, 0);
+ else
+ gpiod_set_value(flash->platform_data->power_gpio, 0);
return ret;
}
@@ -407,21 +423,75 @@ static int adp1653_resume(struct device *dev)
#endif /* CONFIG_PM */
+static int adp1653_of_init(struct i2c_client *client,
+ struct adp1653_flash *flash,
+ struct device_node *node)
+{
+ u32 val;
+ struct adp1653_platform_data *pd;
+ struct device_node *child;
+
+ if (!node)
+ return -EINVAL;
+
+ pd = devm_kzalloc(&client->dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+ flash->platform_data = pd;
+
+ child = of_get_child_by_name(node, "flash");
+ if (!child)
+ return -EINVAL;
+ if (of_property_read_u32(child, "flash-timeout-microsec", &val))
+ return -EINVAL;
+
+ pd->max_flash_timeout = val;
+ if (of_property_read_u32(child, "flash-max-microamp", &val))
+ return -EINVAL;
+ pd->max_flash_intensity = val/1000;
+
+ if (of_property_read_u32(child, "max-microamp", &val))
+ return -EINVAL;
+ pd->max_torch_intensity = val/1000;
+
+ child = of_get_child_by_name(node, "indicator");
+ if (!child)
+ return -EINVAL;
+ if (of_property_read_u32(child, "max-microamp", &val))
+ return -EINVAL;
+ pd->max_indicator_intensity = val;
+
+ if (!of_find_property(node, "gp
Re: [PATCHv4] media: i2c/adp1653: devicetree support for adp1653
Hi!
> > Fixed feedback by Sakari.
> >
> > Please apply,
>
> There is no need to ask for patches to be applied IMHO. It is expected
> that people post patches wanting them to be applied unless there is an
> RFC prefix in the subject or say explicitly that the patch is for
> testing and should not be picked.
See history of this patch.
> > diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> > b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
>
> When adding DT bindings, the Documentation portion should be in a
> separate patch and should come in the series before the patch
> implementing the binding. That makes the change easier to review,
> please take a look to points 1 and 3 in
> Documentation/devicetree/bindings/submitting-patches.txt.
Because actual patch at the end of email is too much eye clutter for
the poor device tree people, I can prepare nice series... producing
more work for me and more noise on the lists? No, thanks.
> > +Required Properties:
> > +
> > + - compatible: Must contain be "adi,adp1653"
> > +
> > + - reg: I2C slave address
> > +
> > + - gpios: References to the GPIO that controls the power for the chip.
>
> The convention nowadays is to not use unnamed DT properties for GPIOs
> but instead use a prefix that explains what those GPIOs are used for.
> So something like "power-gpios" or "power-gpio" (if there is only one
> GPIO) will be more suitable. Please take a look to
> Documentation/gpio/board.txt for more details.
Ok. Actually, reading docs below, "power-gpio" will not work, and it
needs to be "power-gpios", right?
> > + if (!of_find_property(node, "gpios", NULL)) {
> > + dev_err(&client->dev, "No gpio node\n");
> > + return -EINVAL;
> > + }
> > +
> > + pd->power_gpio = of_get_gpio_flags(node, 0, &flags);
>
> The old integer-based GPIO interface is deprecated and we want to get
> rid of it so please use the descriptor-based for new code. For example
> you want to use gpiod_get() instead of of_get_gpio_flags().
> Documentation/gpio/gpio.txt describes the new interface.
Ok.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653
Hi! > Hi Pawel, I'm still Pavel. v, not w. > > > Hi Pawel, > > > A corresponding change to the N900 dts would be very nice. > > > > Corresponding change to the dts will come in separate patch. Or do you > > have n900 for testing? > > Yes, it should be a separate patch, I agree. > > I do have one but I can't say when I'd have time to test it. I'm fine with > you having tested it though. > > > > I think you're missing change to adp1653_i2c_driver.driver.of_match_table. > > > > It actually worked for me, which means device tree somehow does it > > magic. > > By magic? :-) It probably just ends up comparing the device and the driver > names. How about adding the of_match_table? I guess it uses adp1653_id_table. I'd hade to add redundand information, because if it would just mask the errors if the code changed... Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
[PATCHv4] media: i2c/adp1653: devicetree support for adp1653
We are moving to device tree support on OMAP3, but that currently
breaks ADP1653 driver. This adds device tree support, plus required
documentation.
Signed-off-by: Pavel Machek
---
Fixed feedback by Sakari.
Please apply,
Pavel
diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
new file mode 100644
index 000..0fc28a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -0,0 +1,37 @@
+* Analog Devices ADP1653 flash LED driver
+
+Required Properties:
+
+ - compatible: Must contain be "adi,adp1653"
+
+ - reg: I2C slave address
+
+ - gpios: References to the GPIO that controls the power for the chip.
+
+There are two led outputs available - flash and indicator. One led is
+represented by one child node, nodes need to be named "flash" and "indicator".
+
+Required properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+
+Required properties of the flash LED child node:
+
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+ adp1653: led-controller@30 {
+ compatible = "adi,adp1653";
+ reg = <0x30>;
+ gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+ flash {
+ flash-timeout-us = <50>;
+ flash-max-microamp = <32>;
+ max-microamp = <5>;
+ };
+ indicator {
+ max-microamp = <17500>;
+ };
+ };
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index 873fe19..6d57b16 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -8,6 +8,7 @@
* Contributors:
* Sakari Ailus
* Tuukka Toivonen
+ * Pavel Machek
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -34,6 +35,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -306,9 +309,17 @@ adp1653_init_device(struct adp1653_flash *flash)
static int
__adp1653_set_power(struct adp1653_flash *flash, int on)
{
- int ret;
+ int ret = 0;
+
+ if (flash->platform_data->power) {
+ ret = flash->platform_data->power(&flash->subdev, on);
+ } else {
+ gpio_set_value(flash->platform_data->power_gpio, on);
+ if (on)
+ /* Some delay is apparently required. */
+ udelay(20);
+ }
- ret = flash->platform_data->power(&flash->subdev, on);
if (ret < 0)
return ret;
@@ -316,8 +327,13 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
return 0;
ret = adp1653_init_device(flash);
- if (ret < 0)
+ if (ret >= 0)
+ return ret;
+
+ if (flash->platform_data->power)
flash->platform_data->power(&flash->subdev, 0);
+ else
+ gpio_set_value(flash->platform_data->power_gpio, 0);
return ret;
}
@@ -407,21 +423,76 @@ static int adp1653_resume(struct device *dev)
#endif /* CONFIG_PM */
+static int adp1653_of_init(struct i2c_client *client,
+ struct adp1653_flash *flash,
+ struct device_node *node)
+{
+ u32 val;
+ struct adp1653_platform_data *pd;
+ enum of_gpio_flags flags;
+ struct device_node *child;
+
+ if (!node)
+ return -EINVAL;
+
+ pd = devm_kzalloc(&client->dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+ flash->platform_data = pd;
+
+ child = of_get_child_by_name(node, "flash");
+ if (!child)
+ return -EINVAL;
+ if (of_property_read_u32(child, "flash-timeout-microsec", &val))
+ return -EINVAL;
+
+ pd->max_flash_timeout = val;
+ if (of_property_read_u32(child, "flash-max-microamp", &val))
+ return -EINVAL;
+ pd->max_flash_intensity = val/1000;
+
+ if (of_property_read_u32(child, "max-microamp", &val))
+ return -EINVAL;
+ pd->max_torch_intensity = val/1000;
+
+ child = of_get_child_by_name(node, "indicator");
+ if (!child)
+ return -EINVAL;
+ if (of_property_read_u32(child, "max-microamp", &val))
+ return -EINVAL;
+ pd->max_indicator_intensity = val;
+
+ if (!of_find_property(node,
Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653
Hi!
> Hi Pawel,
>
> My apologies for the very late reply.
>
> On Thu, Apr 02, 2015 at 04:38:46PM +0200, Pavel Machek wrote:
> >
> >
> > We are moving to device tree support on OMAP3, but that currently
> > breaks ADP1653 driver. This adds device tree support, plus required
> > documentation.
> >
> > Signed-off-by: Pavel Machek
> >
> > ---
> >
> > I'm not sure if it is device tree or media framework, either everyone
> > waits for someone else, or noone really cares.
>
> Neither. Some people are unfortuantely very busy with many other things as
> well. :-P
Well.. Being busy is ok. Nitpicking is also ok. But both at the same
time... is not good.
> > Andrew, can you just merge it?
> >
> > Please apply,
>
> Please wait just a while.
>
> I think we can merge this eventually through the linux-media tree, but
> please first see the comments below.
>
> > +Required properties of the flash LED child node:
> > +
> > +- flash-max-microamp : see
> > Documentation/devicetree/bindings/leds/common.txt
> > +- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
>
> The documentation says that the maximum value is used if these values are
> not specified. I think I'd make these optional.
I'd rather not: when you make a typo in dts, it would supply maximum
available current, potentially damaging the LED. You will not be able
to tell brightness difference with naked eye...
> > __adp1653_set_power(struct adp1653_flash *flash, int on)
> > {
> > - int ret;
> > + int ret = 0;
> > +
> > + if (flash->platform_data->power) {
> > + ret = flash->platform_data->power(&flash->subdev, on);
>
> The power() callback should be dropped. It's controlling a GPIO. But that
> can be done later on. The alternative is a patch before this one.
I'd prefer to do it later; we want to keep functionality on N900
without DTS, too.
> > flash = devm_kzalloc(&client->dev, sizeof(*flash), GFP_KERNEL);
> > if (flash == NULL)
> > return -ENOMEM;
> >
> > flash->platform_data = client->dev.platform_data;
> > + if (!flash->platform_data) {
>
> I'd check whether dev->of_node is non-NULL instead.
Ok.
> > @@ -438,10 +510,10 @@ static int adp1653_probe(struct i2c_client *client,
> > goto free_and_quit;
> >
> > flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> > -
>
> I rather liked the newline here. Please don't remove it. :-)
Ok.
> > @@ -464,7 +536,7 @@ static const struct i2c_device_id adp1653_id_table[] = {
> > };
> > MODULE_DEVICE_TABLE(i2c, adp1653_id_table);
> >
> > -static struct dev_pm_ops adp1653_pm_ops = {
> > +static const struct dev_pm_ops adp1653_pm_ops = {
> > .suspend= adp1653_suspend,
> > .resume = adp1653_resume,
> > };
> >
> >
>
> A corresponding change to the N900 dts would be very nice.
Corresponding change to the dts will come in separate patch. Or do you
have n900 for testing?
> I think you're missing change to adp1653_i2c_driver.driver.of_match_table.
It actually worked for me, which means device tree somehow does it
magic.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: [PATCH] ti-soc-thermal: implement omap3 support
> > +/* Thresholds and limits for OMAP34XX MPU temperature sensor */
> > +static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
> > + .min_freq = 32768,
> > + .max_freq = 32768,
> > + .max_temp = -99000,
> > + .min_temp = 99000,
>
> This looks mixed up. Also, perhaps use -4 to 125000 to match the
> table below?
Yes, that looks reasonable, thanks for review. v2 in minute or so.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
[PATCHv2] ti-soc-thermal: implement omap3 support
This adds support for OMAP3 chips to ti-soc-thermal. As requested by
TI people, it is marked unreliable and warning is printed.
Signed-off-by: Pavel Machek
---
Patch is against thermal linus tree, please apply so that it has
chance for 4.1.
v2: fixed min/max temp
diff --git a/drivers/thermal/ti-soc-thermal/Kconfig
b/drivers/thermal/ti-soc-thermal/Kconfig
index bd4c7be..d414c2d 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -21,6 +21,21 @@ config TI_THERMAL
This includes trip points definitions, extrapolation rules and
CPU cooling device bindings.
+config OMAP3_THERMAL
+ bool "Texas Instruments OMAP3 thermal support"
+ depends on TI_SOC_THERMAL
+ depends on ARCH_OMAP3
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP3 SoC family. The current chips supported are:
+ - OMAP3430
+
+ OMAP3 chips normally don't need thermal management, and sensors in
+ this generation are not accurate, nor they are very close to
+ the important hotspots.
+
+ Say 'N' here.
+
config OMAP4_THERMAL
bool "Texas Instruments OMAP4 thermal support"
depends on TI_SOC_THERMAL
diff --git a/drivers/thermal/ti-soc-thermal/Makefile
b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..0f89bdf 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)+= ti-soc-thermal.o
ti-soc-thermal-y := ti-bandgap.o
ti-soc-thermal-$(CONFIG_TI_THERMAL)+= ti-thermal-common.o
ti-soc-thermal-$(CONFIG_DRA752_THERMAL)+= dra752-thermal-data.o
+ti-soc-thermal-$(CONFIG_OMAP3_THERMAL) += omap3-thermal-data.o
ti-soc-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal-data.o
ti-soc-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 000..86a4e2d
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,103 @@
+/*
+ * OMAP3 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Note
+ * http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
+ * 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used"
+ *
+ * Also TI says:
+ * Just be careful when you try to make thermal policy like decisions
+ * based on this sensor. Placement of the sensor w.r.t the actual logic
+ * generating heat has to be a factor as well. If you are just looking
+ * for an approximation temperature (thermometerish kind), you might be
+ * ok with this. I am not sure we'd find any TI data around this.. just a
+ * heads up.
+ */
+
+#include "ti-thermal.h"
+#include "ti-bandgap.h"
+
+/*
+ * OMAP34XX has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap34xx_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = 0,
+ .bgap_soc_mask = BIT(8),
+ .bgap_eocz_mask = BIT(7),
+ .bgap_dtemp_mask = 0x7f,
+
+ .bgap_mode_ctrl = 0,
+ .mode_ctrl_mask = BIT(9),
+};
+
+/* Thresholds and limits for OMAP34XX MPU temperature sensor */
+static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
+ .min_freq = 32768,
+ .max_freq = 32768,
+ .max_temp = 125000,
+ .min_temp = -4,
+ .hyst_val = 5000,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ */
+static const int
+omap34xx_adc_to_temp[128] = {
+ -4, -4, -4, -4, -4, -39000, -38000, -36000,
+ -34000, -32000, -31000, -29000, -28000, -26000, -25000, -24000,
+ -22000, -21000, -19000, -18000, -17000, -15000, -14000, -12000,
+ -11000, -9000, -8000, -7000, -5000, -4000, -2000, -1000, ,
+ 1000, 3000, 4000, 5000, 7000, 8000, 1, 11000, 13000, 14000,
+ 15000, 17000, 18000, 2, 21000, 22000, 24000, 25000, 27000,
+ 28000, 3, 31000, 32000, 34000, 35000, 37000, 38000, 39000,
+ 41000, 42000, 44000, 45000, 47000, 48000, 49000, 51000, 52000,
+ 53000, 55000, 56000, 58000, 59000, 6, 62000, 63000, 65000,
+ 66000, 67000, 69000, 7, 72000, 73000, 74000, 76000, 77000,
+ 79000, 8, 81000, 83000, 84000,
[PATCHv3] media: i2c/adp1653: devicetree support for adp1653
We are moving to device tree support on OMAP3, but that currently
breaks ADP1653 driver. This adds device tree support, plus required
documentation.
Signed-off-by: Pavel Machek
---
I'm not sure if it is device tree or media framework, either everyone
waits for someone else, or noone really cares.
Andrew, can you just merge it?
Please apply,
Pavel
diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
new file mode 100644
index 000..0fc28a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -0,0 +1,37 @@
+* Analog Devices ADP1653 flash LED driver
+
+Required Properties:
+
+ - compatible: Must contain be "adi,adp1653"
+
+ - reg: I2C slave address
+
+ - gpios: References to the GPIO that controls the power for the chip.
+
+There are two led outputs available - flash and indicator. One led is
+represented by one child node, nodes need to be named "flash" and "indicator".
+
+Required properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+
+Required properties of the flash LED child node:
+
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+ adp1653: led-controller@30 {
+ compatible = "adi,adp1653";
+ reg = <0x30>;
+ gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+ flash {
+ flash-timeout-us = <50>;
+ flash-max-microamp = <32>;
+ max-microamp = <5>;
+ };
+ indicator {
+ max-microamp = <17500>;
+ };
+ };
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index 873fe19..0341009 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -8,6 +8,7 @@
* Contributors:
* Sakari Ailus
* Tuukka Toivonen
+ * Pavel Machek
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -34,6 +35,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -306,9 +309,17 @@ adp1653_init_device(struct adp1653_flash *flash)
static int
__adp1653_set_power(struct adp1653_flash *flash, int on)
{
- int ret;
+ int ret = 0;
+
+ if (flash->platform_data->power) {
+ ret = flash->platform_data->power(&flash->subdev, on);
+ } else {
+ gpio_set_value(flash->platform_data->power_gpio, on);
+ if (on)
+ /* Some delay is apparently required. */
+ udelay(20);
+ }
- ret = flash->platform_data->power(&flash->subdev, on);
if (ret < 0)
return ret;
@@ -316,8 +327,13 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
return 0;
ret = adp1653_init_device(flash);
- if (ret < 0)
+ if (ret >= 0)
+ return ret;
+
+ if (flash->platform_data->power)
flash->platform_data->power(&flash->subdev, 0);
+ else
+ gpio_set_value(flash->platform_data->power_gpio, 0);
return ret;
}
@@ -407,21 +423,77 @@ static int adp1653_resume(struct device *dev)
#endif /* CONFIG_PM */
+static int adp1653_of_init(struct i2c_client *client,
+ struct adp1653_flash *flash,
+ struct device_node *node)
+{
+ u32 val;
+ struct adp1653_platform_data *pd;
+ enum of_gpio_flags flags;
+ int gpio;
+ struct device_node *child;
+
+ if (!node)
+ return -EINVAL;
+
+ pd = devm_kzalloc(&client->dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+ flash->platform_data = pd;
+
+ child = of_get_child_by_name(node, "flash");
+ if (!child)
+ return -EINVAL;
+ if (of_property_read_u32(child, "flash-timeout-microsec", &val))
+ return -EINVAL;
+
+ pd->max_flash_timeout = val;
+ if (of_property_read_u32(child, "flash-max-microamp", &val))
+ return -EINVAL;
+ pd->max_flash_intensity = val/1000;
+
+ if (of_property_read_u32(child, "max-microamp", &val))
+ return -EINVAL;
+ pd->max_torch_intensity = val/1000;
+
+ child = of_get_child_by_name(node, "indicator");
+ if (!child)
+ return -EINVAL;
+ if (of_property_read_u32(child, &qu
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi!
> > As I explained in some other mail, those tables should not be
> > neccessary at all. They can be computed from li-ion characteristics
> > and internal resistance, and assumed current during charge and
> > discharge.
>
> I already explained that we do not know the charging and discharging
> current well enough for such a calculation.
>
> And I explained that the “internal resistance” is a system (battery + cables +
> connectors + other circuits) parameter that is not easy to derive or measure
> and type into the .dts source code.
>
> At least I have no idea how I should find it out for my boards. While I can
> easily determine the curves (and we already have them for the platform_data
> driver).
>
> Please propose your own code doing that so that we can test if it is
> better.
So, how does this look?
It looks to me like you have cca 0.1 Ohm resistance in your system,
and are using cca 75mA while discharging, and charge by cca 1.4A. (And
these are all the coefficients the code should need; rest is battery
characteristics -- common to all li-ions, and charger characteristics
-- that will be common to all cellphones. If current can be measured,
this code should go more precise answers).
pavel@amd:~/g/tui/ofone$ ./liion_maps
Charging
Voltage 4.2 V ; table 100 % internal voltage 4.18 V current 0.233 A computed
97 %
Voltage 4.1 V ; table 75 % internal voltage 4.08 V current 0.233 A computed
87 %
Voltage 4.0 V ; table 55 % internal voltage 3.93 V current 0.700 A computed
69 %
Voltage 3.9 V ; table 25 % internal voltage 3.76 V current 1.400 A computed
26 %
Voltage 3.8 V ; table 5 % internal voltage 3.66 V current 1.400 A computed
3 %
Voltage 3.7 V ; table 2 % internal voltage 3.56 V current 1.400 A computed
2 %
Voltage 3.6 V ; table 1 % internal voltage 3.46 V current 1.400 A computed
1 %
Voltage 3.3 V ; table 0 % internal voltage 3.16 V current 1.400 A computed
-1 %
Badness 395.4861761427434
Discharging
Voltage 4.2 V ; table 100 % internal voltage 4.21 V current -0.075 A
computed 100 %
Voltage 4.1 V ; table 95 % internal voltage 4.11 V current -0.075 A computed
91 %
Voltage 4.0 V ; table 70 % internal voltage 4.01 V current -0.075 A computed
79 %
Voltage 3.8 V ; table 50 % internal voltage 3.81 V current -0.075 A computed
46 %
Voltage 3.7 V ; table 10 % internal voltage 3.71 V current -0.075 A computed
3 %
Voltage 3.6 V ; table 5 % internal voltage 3.61 V current -0.075 A computed
2 %
Voltage 3.3 V ; table 0 % internal voltage 3.31 V current -0.075 A computed
0 %
Badness 171.69576218433212
> > Running below 3.3V.. not really. At that point, the battery is really
> > _empty_, and voltage is going down really really fast.
>
> It is the diffference between 2% and 0% where a fuel indication might
> be most important…
> > Plus, you are damaging the battery at that point.
>
> The power controller will shut down - but the driver should report
> reasonable (but IMHO not necessarily perfect) values until the last
> moment.
It is tricky to do a good job near 0%... or anywhere else. See for
example
http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf
You start a call, percentage goes down, end a call, it will go
back up. I'm pretty sure you will not be able to make a call with "5%"
indication from your code at low battery temperature (say -10C).
Anyway, see above, I think I provide reasonable values even in that range.
Signed-off-by: Pavel Machek
Pavel
#!/usr/bin/python3
import math
def percent_internal(v):
u = 0.0387-(1.4523*(3.7835-v))
if u < 0:
# Formula above does gives 19.66% for 3.756, and refuses to
# work below that. Assume 3.3V is empty battery, and provide
# linear dependency below that.
u = (v - 3.3) * ((3.756 - 3.3) * 19.66)
return u
return (0.1966+math.sqrt(u))*100
charging = [ [4200, 100], [4100, 75], [4000, 55], [3900, 25], [3800, 5], [3700,
2], [3600, 1], [3300, 0] ]
discharging = [ [4200, 100], [4100, 95], [4000, 70], [3800, 50], [3700, 10],
[3600, 5], [3300, 0] ]
# current > 0: charging
def percent_ohm(v, current):
v_int = v - current * 0.1
print(" internal voltage %1.2f V current %.3f A " % (v_int, current),
end='')
return percent_internal(v_int)
def percent(v, charging):
if charging:
# Charger model. Chargers will do constant current then
# constant voltage, so current will go down as voltage
# approaches 4.2V
i = 2.8
if v >= 4.:
i = i/2
if v >= 4.05:
i = i/3
else:
i = -0.15
# With current forced to 0, we get badness 4014 and 258
# 2.5A, sloped: badness 576
# +4A -> badness 1293
# +3A -> badness 890
[PATCH] ti-soc-thermal: implement omap3 support
This adds support for OMAP3 chips to ti-soc-thermal. As requested by
TI people, it is marked unreliable and warning is printed.
Signed-off-by: Pavel Machek
---
Patch is against thermal linus tree, please apply so that it has
chance for 4.1.
diff --git a/drivers/thermal/ti-soc-thermal/Kconfig
b/drivers/thermal/ti-soc-thermal/Kconfig
index bd4c7be..d414c2d 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -21,6 +21,21 @@ config TI_THERMAL
This includes trip points definitions, extrapolation rules and
CPU cooling device bindings.
+config OMAP3_THERMAL
+ bool "Texas Instruments OMAP3 thermal support"
+ depends on TI_SOC_THERMAL
+ depends on ARCH_OMAP3
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP3 SoC family. The current chips supported are:
+ - OMAP3430
+
+ OMAP3 chips normally don't need thermal management, and sensors in
+ this generation are not accurate, nor they are very close to
+ the important hotspots.
+
+ Say 'N' here.
+
config OMAP4_THERMAL
bool "Texas Instruments OMAP4 thermal support"
depends on TI_SOC_THERMAL
diff --git a/drivers/thermal/ti-soc-thermal/Makefile
b/drivers/thermal/ti-soc-thermal/Makefile
index 1226b24..0f89bdf 100644
--- a/drivers/thermal/ti-soc-thermal/Makefile
+++ b/drivers/thermal/ti-soc-thermal/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_TI_SOC_THERMAL)+= ti-soc-thermal.o
ti-soc-thermal-y := ti-bandgap.o
ti-soc-thermal-$(CONFIG_TI_THERMAL)+= ti-thermal-common.o
ti-soc-thermal-$(CONFIG_DRA752_THERMAL)+= dra752-thermal-data.o
+ti-soc-thermal-$(CONFIG_OMAP3_THERMAL) += omap3-thermal-data.o
ti-soc-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal-data.o
ti-soc-thermal-$(CONFIG_OMAP5_THERMAL) += omap5-thermal-data.o
diff --git a/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
new file mode 100644
index 000..86a4e2d
--- /dev/null
+++ b/drivers/thermal/ti-soc-thermal/omap3-thermal-data.c
@@ -0,0 +1,103 @@
+/*
+ * OMAP3 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Copyright (C) 2014 Pavel Machek
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Note
+ * http://www.ti.com/lit/er/sprz278f/sprz278f.pdf "Advisory
+ * 3.1.1.186 MMC OCP Clock Not Gated When Thermal Sensor Is Used"
+ *
+ * Also TI says:
+ * Just be careful when you try to make thermal policy like decisions
+ * based on this sensor. Placement of the sensor w.r.t the actual logic
+ * generating heat has to be a factor as well. If you are just looking
+ * for an approximation temperature (thermometerish kind), you might be
+ * ok with this. I am not sure we'd find any TI data around this.. just a
+ * heads up.
+ */
+
+#include "ti-thermal.h"
+#include "ti-bandgap.h"
+
+/*
+ * OMAP34XX has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+static struct temp_sensor_registers
+omap34xx_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = 0,
+ .bgap_soc_mask = BIT(8),
+ .bgap_eocz_mask = BIT(7),
+ .bgap_dtemp_mask = 0x7f,
+
+ .bgap_mode_ctrl = 0,
+ .mode_ctrl_mask = BIT(9),
+};
+
+/* Thresholds and limits for OMAP34XX MPU temperature sensor */
+static struct temp_sensor_data omap34xx_mpu_temp_sensor_data = {
+ .min_freq = 32768,
+ .max_freq = 32768,
+ .max_temp = -99000,
+ .min_temp = 99000,
+ .hyst_val = 5000,
+};
+
+/*
+ * Temperature values in milli degree celsius
+ */
+static const int
+omap34xx_adc_to_temp[128] = {
+ -4, -4, -4, -4, -4, -39000, -38000, -36000,
+ -34000, -32000, -31000, -29000, -28000, -26000, -25000, -24000,
+ -22000, -21000, -19000, -18000, -17000, -15000, -14000, -12000,
+ -11000, -9000, -8000, -7000, -5000, -4000, -2000, -1000, ,
+ 1000, 3000, 4000, 5000, 7000, 8000, 1, 11000, 13000, 14000,
+ 15000, 17000, 18000, 2, 21000, 22000, 24000, 25000, 27000,
+ 28000, 3, 31000, 32000, 34000, 35000, 37000, 38000, 39000,
+ 41000, 42000, 44000, 45000, 47000, 48000, 49000, 51000, 52000,
+ 53000, 55000, 56000, 58000, 59000, 6, 62000, 63000, 65000,
+ 66000, 67000, 69000, 7, 72000, 73000, 74000, 76000, 77000,
+ 79000, 8, 81000, 83000, 84000, 85000, 87000, 88000,
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi! > > >> +io-channels = <&twl_madc 1>, > > >> + <&twl_madc 10>, > > >> + <&twl_madc 12>; > > >> +io-channel-names = "temp", > > >> + "ichg", > > >> + "vbat"; > > >> +}; > > > > > > Rather than just making platform_data into device tree properties.. > > > > > > Can't you hide the these custom properties behind the compatible flag? > > > > > > You can initialize that data in the driver based on the compatible > > > flag and the match data. > > > > > > This makes sense if you can group things to similar configurations. > > > > Maybe I have not completely understood your proposal. > > > > Do you mean to go back to have big parameter tables for each device/battery > > combination in the driver code and the compatible flag (e.g. compatible = > > “board17”) > > chooses the right data set for the charging map and channels? > > If you can somehow group them, then yes. Not for every board if there > are many of them naturally. > > > I thought this is what the DT was introduced for - to have the same driver > > code but adapt to different boards depending on hardware variations. > > Yeah but you also need to consider the issues related to introducing > new device tree properties. The device tree properties introduced > should be generic where possible. > > > And batteries have very different characteristics and vary between devices… > > Right. Maybe that has been already agreed on to use capacity-uah for > batteries in general? In that case I have not problem with that as > it's a generic property :) > > > The charging maps are depending on the battery type connected to the twl4030 > > and which madc channel is which value is also a little hardware dependent > > (although the twl4030 doesn’t give much choice). > > Just to consider alternatives before introducing driver specific > property for the maps.. Maybe here you could have few different type > of maps and select something safe by default? Of course it could be this > is higly board specific, I think some devices may be able to run below > 3.3V for example.. As I explained in some other mail, those tables should not be neccessary at all. They can be computed from li-ion characteristics and internal resistance, and assumed current during charge and discharge. Running below 3.3V.. not really. At that point, the battery is really _empty_, and voltage is going down really really fast. Plus, you are damaging the battery at that point. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
4.0-rc1 to -rc4: random sound and speed problems on n900
Hi! 4.0-rc4 (or more specifically 7b09ac704bac2de5bf0362793edc22a0094e381c based kernel boots really really slowly on n900, and there's an ugly backtrace from sound in the dmesg. I re-tested 4.0-rc4 and it worked ok. Weird. I guess we have some random stuff going on during boot Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv2] ti-soc-thermal: request temperature periodically if hw can't do that itself
On Tue 2015-03-24 12:30:34, Eduardo Valentin wrote: > On Sun, Jan 18, 2015 at 09:24:47PM +0100, Pavel Machek wrote: > > > > When periodic mode is not enabled, it is neccessary to force reads. > > > > Signed-off-by: Pavel Machek > > This is a malformed patch. here is patch output (or git am) > patching file drivers/thermal/ti-soc-thermal/ti-bandgap.c > patch: malformed patch at line 68: (english) > http://www.livejournal.com/~pavelmachek Sorry about that. You should have fixed [PATCHv3] in your inbox now. > I would really recommend you to use git to send your patches to avoid > such problems. Can you please resend this patch in its proper > format? Done. I verified that the other 2 patches are ok, by applying them in following order: Subject: [PATCHv3] ti-soc-thermal: request temperature periodically if hw can't do that itself Date: Sun, 18 Jan 2015 21:20:51 +0100 From: Pavel Machek Subject: [PATCHv2] ti-soc-thermal: implement eocz bit to make driver useful on omap3 Date: Sun, 18 Jan 2015 21:17:10 +0100 From: Pavel Machek Subject: [PATCHv2] cleanup ti-soc-thermal Best regards and thanks for patience, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
[PATCHv3] ti-soc-thermal: request temperature periodically if hw can't do that itself
When periodic mode is not enabled, it is neccessary to force reads.
Signed-off-by: Pavel Machek
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 62a5d44..ec533e7 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -43,6 +43,8 @@
#include "ti-bandgap.h"
+static int ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id);
+
/*** Helper functions to access registers and their bitfields ***/
/**
@@ -852,6 +854,12 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp,
int id,
if (ret)
return ret;
+ if (!TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
+ ret = ti_bandgap_force_single_read(bgp, id);
+ if (ret)
+ return ret;
+ }
+
spin_lock(&bgp->lock);
temp = ti_bandgap_read_temp(bgp, id);
spin_unlock(&bgp->lock);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: [PATCH 13/14] twl4030_charger: Increase current carefully while watching voltage.
Hi!
> The USB Battery Charging spec (BC1.2) suggests a dedicated
> charging port can deliver from 0.5 to 5.0A at between 4.75 and 5.25
> volts.
>
> To choose the "correct" current voltage setting requires a trial
> and error approach: try to draw current and see if the voltage drops
> too low.
>
> Even with a configured Standard Downstream Port, it may not be possible
> to reliably pull 500mA - depending on cable quality and source
> quality I have reports of charging failure due to the voltage dropping
> too low.
>
> To address both these concerns, this patch introduce incremental
> current setting.
> The current pull from VBUS is increased in steps of 20mA every 100ms
> until the target is reached or until the measure voltage drops below
> 4.75V. If the voltage does go too low, the target current is reduced
> by 20mA and kept there.
Still nervous. If it is possible to overheat the charger, without
tripping internal fuse, then you'll do it.
> This applies to currents selected automatically, or to values
> set via sysfs. So setting a large value will cause the maximum
> available to be used - up to the limit of 1.7A imposed by the
> hardware.
>
> + printk("v=%d cur=%d target=%d\n", v, bci->usb_cur,
> +bci->usb_cur_target);
dev_info() and a bit better message, or drop it for production?
> + if (v < USB_MIN_VOLT) {
> + /* Back up and stop adjusting. */
> + bci->usb_cur -= USB_CUR_STEP;
> + bci->usb_cur_target = bci->usb_cur;
More importantly how does it work with device drawing power for
operation, too?
Imagine device need 500mA with wifi hotspot, nearly nothing while idle.
Idle device. Code will find that it can charge using 1A, backs up to
0.9A. User starts hotspot. Now device will draw 1.4A, overloading the
charger and not charging at all...?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
Re: [PATCH 02/14] twl4030_charger: use devres for power_supply_register and kzalloc.
On Mon 2015-03-23 10:20:28, NeilBrown wrote: > From: NeilBrown > > Final allocations/registrations are now managed by devres. > > Signed-off-by: NeilBrown Patches 1,2: Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv2] thermal: add omap3 support
On Mon 2015-03-23 10:31:51, Eduardo Valentin wrote: > On Sun, Jan 18, 2015 at 09:28:24PM +0100, Pavel Machek wrote: > > > > Add support for omap3430 sensor. Tested on Nokia N900. > > > > Fix help text to be closer to english. > > > > Ifdefs in ti-bandgap.h are not neccessary, as users have #ifdefs, > > already. > > > > Signed-off-by: Pavel Machek > > You need to update the driver device tree binding documentation. Please > include an example of its usage there. > > Also, a separate patch with the required DT changes is always > welcome. I can do it, but can you merge: Date: Sun, 18 Jan 2015 21:24:47 +0100 From: Pavel Machek Subject: [PATCHv2] ti-soc-thermal: request temperature periodically if hw can't do that itself Date: Sun, 18 Jan 2015 21:20:51 +0100 From: Pavel Machek Subject: [PATCHv2] ti-soc-thermal: implement eocz bit to make driver useful on omap3 Date: Sun, 18 Jan 2015 21:17:10 +0100 From: Pavel Machek Subject: [PATCHv2] cleanup ti-soc-thermal First? They are nicely split, as you requested, and I already have too many patches in flight. Thanks for the comments, I'll fix them in my local tree. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv2] thermal: add omap3 support
On Sat 2015-03-14 19:02:40, Pavel Machek wrote: > On Fri 2015-03-13 12:53:45, Eduardo Valentin wrote: > > > > Hey Pavel, > > > > On Fri, Mar 13, 2015 at 01:09:35PM +0100, Pavel Machek wrote: > > > Hi! > > > > > > I checked 4.0-rc3 and linux-next as of today, and can not see omap3 > > > thermal support. Can you apply the patches? > > > > Yeah, it should be possible. Apologize, it really fell into the cracks. > > > > There is a comment on it though. Please check my concern in you v2. > > And there's explanation for that concern :-). Let me know what you > need. ...ping? It would be good to get this into 4.1. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi! > > to introduce coefficients for temperature and discharge rate? > What do you mean? Nothing like that is used in current driver why do > we need to add it? > >>> > >>> Well, conversion between Li-ion's voltage and state of charge at 0 > >>> current is well known: > >> > >> We can’t measure at 0 current since the OMAP is driven from battery > >> and charger and may also draw some mA… > > > > Yes, but you know how many mA you are taking just now. So if you knew > > the internal resistance, you could compute the voltage at 0 > > current. (And it should also work during charging, as long as you know > > how much current is going in.) > > As far as I understand the twl4030 charger and MADC it is not possible to > separate these values. It is only reporting the inflow from charger to > battery + system. So you don’t know how many mA are supplying the system > and how many mA are left over for charging. > > You can only assume how much the system is drawing while running (something > between 50 and 600 mA but this depends on system activities, power state > of peripherald and e.g. backlight being switched on). > > I think your basic assumption that we know any time how many mA the system > is taking is not given. So.. you won't be able to get exact value while charging, but you get one while discharging, which is what really matters...? > > Yes, and that coefficient should be internal battery resistance ;-). > > But where do you know this value from to write it into a DT file? > Usually you can’t measure it easily and for some batteries you don’t have > a data sheet. > > Contrary, the calibration curves can easily be measured on the device > (assuming that the charge level decreases/increases linearly over time > between Full and Empty). If you can copy it from the data sheet, that's the easiest option. If not, you should be able to easily compute it from the charge/discharge curves or from measured voltage at different loads. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi! > >>> to introduce coefficients for temperature and discharge rate? > >> What do you mean? Nothing like that is used in current driver why do > >> we need to add it? > > > > Well, conversion between Li-ion's voltage and state of charge at 0 > > current is well known: > > We can’t measure at 0 current since the OMAP is driven from battery > and charger and may also draw some mA… Yes, but you know how many mA you are taking just now. So if you knew the internal resistance, you could compute the voltage at 0 current. (And it should also work during charging, as long as you know how much current is going in.) > >def percent(m, v): > > u = 0.0387-(1.4523*(3.7835-v)) > >if u < 0: > >return 0 > > return (0.1966+math.sqrt(u))*100 > > > > And there's not much to calibrate there, and it should become library > > helper function; there's no need to write it to every single dts. > > > > The charge/discharge difference is due to internal battery resistance, > > and Ohm's law. (Then, you should not need different values for > > charging/discharging case.) > > Yes, and that also depends on the board and battery type. So you always > need to specify some battery specific coefficient for that in the DT. Yes, and that coefficient should be internal battery resistance ;-). > We simply did choose a table, because calculating the right coefficients > is more complex and getting the table values can easily be done from > running one full charge-discharge-charge cycle. Well.. One set of coefficients would be kind of ok. But you are doing two, because it really depends on current, not charge/discharge. So why not do it right, for all currents...? > > With your aproach, you'll get lower percentage when phone is under > > load vs. idle. Taking internal resistance into account would give you > > more precise readings. (Attached, old patch for zaurus shows the > > needed computation). > > This is why we have a charging and a discharging table to compensate > for this effect. Yes, but there's very different current during "idle" phone and during call (for example). So yes, you are compensating for different current during charge and discharge, but it is possible to do better. > > I guess this should go into library somewhere, because many machines > > need similar code. > > Is a library easier to maintain and handle than just a set of table > values? I think so, yes, because otherwise you need a set of tables for each machine. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
On Tue 2015-03-17 10:07:12, Dr. H. Nikolaus Schaller wrote: > > Am 17.03.2015 um 09:47 schrieb Pavel Machek : > > > Hi! > > > >>>> diff --git > >>>> a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > >>>> > >>>> b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > >>>> new file mode 100644 > >>>> index 000..bb3580c > >>>> --- /dev/null > >>>> +++ > >>>> b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > >>>> @@ -0,0 +1,43 @@ > >>>> +twl4030_madc_battery > >>>> + > >>>> +Required properties: > >>>> + - compatible : "ti,twl4030-madc-battery" > >>>> + - capacity-uah : battery capacity in uAh > >>> > >>> Could we make it capacity-uAh ? > >> This name was suggested by Mark Rutland [1] and naming convention > >> should be all lowercase. There exists already bindings > >> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent. > > > > Messing up SI units due to "convention" is _stupid_. Don't do it. > > > >>> to introduce coefficients for temperature and discharge rate? > >> What do you mean? Nothing like that is used in current driver why do > >> we need to add it? > > > > Well, conversion between Li-ion's voltage and state of charge at 0 > > current is well known: > > > >def percent(m, v): > > u = 0.0387-(1.4523*(3.7835-v)) > >if u < 0: > >return 0 > > return (0.1966+math.sqrt(u))*100 > > I forgot to ask: does the kernel have a sqrt() function? This could be good enough. https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0/2.6.0-mm1/broken-out/fix-sqrt.patch Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
> > Temperature calibration should have already been done in the underlaying > twl4030 iio driver. > > Discharge rate is the real current flow reported in uA. Also > reported by iio. Ack, but there's rather severe temperature dependency of the lithium battery, which you should take into account if you want to compute "percentage charged". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi!
> >> diff --git
> >> a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >> b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >> new file mode 100644
> >> index 000..bb3580c
> >> --- /dev/null
> >> +++
> >> b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >> @@ -0,0 +1,43 @@
> >> +twl4030_madc_battery
> >> +
> >> +Required properties:
> >> + - compatible : "ti,twl4030-madc-battery"
> >> + - capacity-uah : battery capacity in uAh
> >
> > Could we make it capacity-uAh ?
> This name was suggested by Mark Rutland [1] and naming convention
> should be all lowercase. There exists already bindings
> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
Messing up SI units due to "convention" is _stupid_. Don't do it.
> > to introduce coefficients for temperature and discharge rate?
> What do you mean? Nothing like that is used in current driver why do
> we need to add it?
Well, conversion between Li-ion's voltage and state of charge at 0
current is well known:
def percent(m, v):
u = 0.0387-(1.4523*(3.7835-v))
if u < 0:
return 0
return (0.1966+math.sqrt(u))*100
And there's not much to calibrate there, and it should become library
helper function; there's no need to write it to every single dts.
The charge/discharge difference is due to internal battery resistance,
and Ohm's law. (Then, you should not need different values for
charging/discharging case.)
With your aproach, you'll get lower percentage when phone is under
load vs. idle. Taking internal resistance into account would give you
more precise readings. (Attached, old patch for zaurus shows the
needed computation).
And if you wanted even more precise readings... internal resistance
depends on temperature.
I guess this should go into library somewhere, because many machines
need similar code.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
./drivers/power - ./drivers/power.ofic
diff -X /usr/src/linux/.gitignore -ur ./drivers/power.ofic/Makefile ./drivers/power/Makefile
--- ./drivers/power.ofic/Makefile 2011-03-16 10:11:34.0 +0100
+++ ./drivers/power/Makefile 2011-04-29 15:12:14.0 +0200
@@ -19,7 +19,9 @@
obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
obj-$(CONFIG_BATTERY_TOSA) += tosa_battery.o
+obj-m += spitz_battery.o
obj-$(CONFIG_BATTERY_COLLIE) += collie_battery.o
+obj-m += spitz_battery.o
obj-$(CONFIG_BATTERY_WM97XX) += wm97xx_battery.o
obj-$(CONFIG_BATTERY_BQ20Z75) += bq20z75.o
obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
diff -X /usr/src/linux/.gitignore -ur ./drivers/power.ofic/power_supply_sysfs.c ./drivers/power/power_supply_sysfs.c
--- ./drivers/power.ofic/power_supply_sysfs.c 2011-02-02 10:54:32.0 +0100
+++ ./drivers/power/power_supply_sysfs.c 2011-04-29 15:02:07.0 +0200
@@ -40,7 +40,8 @@
static ssize_t power_supply_show_property(struct device *dev,
struct device_attribute *attr,
- char *buf) {
+ char *buf)
+{
static char *type_text[] = {
"Battery", "UPS", "Mains", "USB",
"USB_DCP", "USB_CDP", "USB_ACA"
@@ -102,7 +103,8 @@
static ssize_t power_supply_store_property(struct device *dev,
struct device_attribute *attr,
- const char *buf, size_t count) {
+ const char *buf, size_t count)
+{
ssize_t ret;
struct power_supply *psy = dev_get_drvdata(dev);
const ptrdiff_t off = attr - power_supply_attrs;
Only in ./drivers/power: spitz_battery.c
./drivers/video - ./drivers/video.ofic
diff -X /usr/src/linux/.gitignore -ur ./drivers/video.ofic/pxafb.c ./drivers/video/pxafb.c
--- ./drivers/video.ofic/pxafb.c 2011-02-02 09:44:53.0 +0100
+++ ./drivers/video/pxafb.c 2011-04-29 14:50:27.0 +0200
@@ -1648,6 +1648,9 @@
#endif
#ifdef CONFIG_PM
+
+static struct pxafb_info *my_fbi;
+
/*
* Power management hooks. Note that we won't be called from IRQ context,
* unlike the blank functions above, so we may sleep.
@@ -1656,6 +1659,8 @@
{
struct pxafb_info *fbi = dev_get_drvdata(dev);
+ my_fbi = fbi;
+
set_ctrlr_state(fbi, C_DISABLE_PM);
return 0;
}
./arch/arm - ./arch/arm.ofic
Binary files ./arch/arm.ofic/boot/Image and ./arch/arm/boot/Image differ
Binary files ./arch/arm.ofic/boot/compressed/piggy.gzip and ./arch/arm/boot/compressed/piggy.gzip differ
Binary files ./arch/arm.ofic/boot/compressed/vmlinux and ./arch/arm/boot/compressed/vmlinux differ
Binary files ./arch/arm.ofic/boot/zImage and ./arch/arm/boot/zImage differ
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/corgi_pm.c ./arch/arm/mach-pxa/corgi_pm.c
--- ./arch/arm.ofic/mach-pxa/corgi_pm.c 2011-02-02 10:30:38.0 +0100
+++ ./arch/arm/mach-pxa/corgi_pm.c 2011-04-29 15:12:15.0 +0200
@@ -43,6 +43,92 @@
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
On Wed 2015-02-04 23:14:32, Marek Belisko wrote: > Signed-off-by: Marek Belisko > --- > .../bindings/power_supply/twl4030_madc_battery.txt | 43 > ++ > 1 file changed, 43 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > > diff --git > a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > new file mode 100644 > index 000..bb3580c > --- /dev/null > +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > @@ -0,0 +1,43 @@ > +twl4030_madc_battery > + > +Required properties: > + - compatible : "ti,twl4030-madc-battery" > + - capacity-uah : battery capacity in uAh Could we make it capacity-uAh ? > + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values > + for charging calibration (see example) > + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values > + for discharging calibration (see example) Would "mV-to-capacity..." be more accurate? Also, would it make sense to introduce coefficients for temperature and discharge rate? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv2] thermal: add omap3 support
On Fri 2015-03-13 12:53:45, Eduardo Valentin wrote: > > Hey Pavel, > > On Fri, Mar 13, 2015 at 01:09:35PM +0100, Pavel Machek wrote: > > Hi! > > > > I checked 4.0-rc3 and linux-next as of today, and can not see omap3 > > thermal support. Can you apply the patches? > > Yeah, it should be possible. Apologize, it really fell into the cracks. > > There is a comment on it though. Please check my concern in you v2. And there's explanation for that concern :-). Let me know what you need. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv2] thermal: add omap3 support
Hi! > > @@ -384,25 +385,10 @@ int ti_bandgap_set_sensor_data(struct ti_bandgap > > *bgp, int id, void *data); > > void *ti_bandgap_get_sensor_data(struct ti_bandgap *bgp, int id); > > int ti_bandgap_get_trend(struct ti_bandgap *bgp, int id, int *trend); > > > > -#ifdef CONFIG_OMAP4_THERMAL > > +extern const struct ti_bandgap_data omap34xx_data; > > extern const struct ti_bandgap_data omap4430_data; > > extern const struct ti_bandgap_data omap4460_data; > > extern const struct ti_bandgap_data omap4470_data; > > -#else > > -#define omap4430_data NULL > > -#define omap4460_data NULL > > -#define omap4470_data NULL > > -#endif > > - > > -#ifdef CONFIG_OMAP5_THERMAL > > extern const struct ti_bandgap_data omap5430_data; > > -#else > > -#define omap5430_data NULL > > -#endif > > - > > -#ifdef CONFIG_DRA752_THERMAL > > extern const struct ti_bandgap_data dra752_data; > > -#else > > -#define dra752_dataNULL > > -#endif > > Pavel, > > Why do we need to remove the existing symbols for other chips in this file to > get OMAP3 support in? > No, I don't need to remove this, and you can safely drop this hunk. OTOH those ifdefs are unneccessary and eye-sore: extern symbol declarations do not really hurt, and .c files already contain enough #ifdefs for other reasons that the symbols will not be needed when it is not configured. Try it, it should work ok. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCHv2] thermal: add omap3 support
Hi! I checked 4.0-rc3 and linux-next as of today, and can not see omap3 thermal support. Can you apply the patches? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Documentation: leds: clarify what 50% brightness means
I played with RGB LED a bit, and we have quite a gap in documentation: what 50% brightness means is non-trivial and very important in case we want to do smooth blinking and color transitions. Signed-off-by: Pavel Machek diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 3646ec8..649d7a6 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -8,6 +8,11 @@ Description: non-zero brightness settings. The value is between 0 and /sys/class/leds//max_brightness. + If LED supports continuous brightness settings, 50% brightness + should correspond to 50% brightness perceived by human, in a similar + manner pixel brightness on monitor does (not 50% PWM). + + What: /sys/class/leds//max_brightness Date: March 2006 KernelVersion: 2.6.17 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: RGB LED control (was Re: "advanced" LED controllers)
On Mon 2015-03-09 11:50:56, Måns Rullgård wrote: > Geert Uytterhoeven writes: > > > Hi Pavel, > > > > On Sun, Mar 8, 2015 at 9:57 PM, Pavel Machek wrote: > >> Ok, so I played with RGB LED a bit, and we have quite a gap in > >> documentation: what 50% brightness means is non-trivial and very > >> important in case we want to do smooth blinking and color transitions. > >> > >> Signed-off-by: Pavel Machek > >> > >> diff --git a/Documentation/ABI/testing/sysfs-class-led > >> b/Documentation/ABI/testing/sysfs-class-led > >> index 3646ec8..649d7a6 100644 > >> --- a/Documentation/ABI/testing/sysfs-class-led > >> +++ b/Documentation/ABI/testing/sysfs-class-led > >> @@ -8,6 +8,11 @@ Description: > >> non-zero brightness settings. The value is between 0 and > >> /sys/class/leds//max_brightness. > >> > >> + If LED supports continuous brightness settings, 50% > >> brightness > >> + should correspond to 50% brightness perceived by human, in > >> a similar > >> + manner pixel brightness on monitor does (not 50% PWM). > > > > How many drivers do it right? How many don't? > > > > For those that don't, perhaps we handle the conversion between perceived and > > pwm in the core, e.g. by adding a new flag to led_classdev.flags to indicate > > the need for conversion? > > Some LED controllers do the right thing in hardware, so any adjustment > done in the core needs to be optional. Do you have example controller that gets it right, btw? Bryan, can you apply the documentation patch so we can start fixing the drivers? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: [PATCH v2] crypto: omap-sham: Check for return value from pm_runtime_get_sync
On Sun 2015-03-08 11:01:01, Pali Rohár wrote: > Function pm_runtime_get_sync could fail and we need to check return > value to prevent kernel crash. > > Signed-off-by: Pali Rohár Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: RGB LED control (was Re: "advanced" LED controllers)
On Mon 2015-03-09 09:08:37, Geert Uytterhoeven wrote: > Hi Pavel, > > On Sun, Mar 8, 2015 at 9:57 PM, Pavel Machek wrote: > > Ok, so I played with RGB LED a bit, and we have quite a gap in > > documentation: what 50% brightness means is non-trivial and very > > important in case we want to do smooth blinking and color transitions. > > > > Signed-off-by: Pavel Machek > > > > diff --git a/Documentation/ABI/testing/sysfs-class-led > > b/Documentation/ABI/testing/sysfs-class-led > > index 3646ec8..649d7a6 100644 > > --- a/Documentation/ABI/testing/sysfs-class-led > > +++ b/Documentation/ABI/testing/sysfs-class-led > > @@ -8,6 +8,11 @@ Description: > > non-zero brightness settings. The value is between 0 and > > /sys/class/leds//max_brightness. > > > > + If LED supports continuous brightness settings, 50% > > brightness > > + should correspond to 50% brightness perceived by human, in > > a similar > > + manner pixel brightness on monitor does (not 50% PWM). > > How many drivers do it right? How many don't? Not sure. leds-lp5523.c gets is wrong. Easy test is to attempt to set "electric indigo" color (http://en.wikipedia.org/wiki/Indigo#Violet-blue) and see what comes out. > For those that don't, perhaps we handle the conversion between perceived and > pwm in the core, e.g. by adding a new flag to led_classdev.flags to indicate > the need for conversion? There is not that many drivers that support smooth power adjustments. But yes, we can probably conversion in the core for trivial case. Unfortunately, we only have 8-bits of precision to work with... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
RGB LED control (was Re: "advanced" LED controllers)
Ok, so I played with RGB LED a bit, and we have quite a gap in documentation: what 50% brightness means is non-trivial and very important in case we want to do smooth blinking and color transitions. Signed-off-by: Pavel Machek diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 3646ec8..649d7a6 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -8,6 +8,11 @@ Description: non-zero brightness settings. The value is between 0 and /sys/class/leds//max_brightness. + If LED supports continuous brightness settings, 50% brightness + should correspond to 50% brightness perceived by human, in a similar + manner pixel brightness on monitor does (not 50% PWM). + + What: /sys/class/leds//max_brightness Date: March 2006 KernelVersion: 2.6.17 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
Re: twl4030_charger: need changes to get probed?
On Sat 2015-03-07 00:12:07, Grazvydas Ignotas wrote: > On Fri, Mar 6, 2015 at 11:57 PM, Pali Rohár wrote: > > On Friday 06 March 2015 22:24:17 Pavel Machek wrote: > >> Hi! > >> > >> According to n900 dts, twl4030-bci (aka charger) should be > >> included. > >> > > > > AFAIK it is not present on n900... > > Right, it uses twl5030 variant without the charger, charging on n900 > is provided by separate chip and for a good reason as twl's charger is > not that good. Forcing the driver to load just ends up with it > accessing non-existent registers over i2c. Ok, but: 1) Why is the twl4030-bci enabled in n900's dts, then and 2) When it is enabled, why it does not load? (I guess there's no way to get to input voltage on n900...?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
twl4030_charger: need changes to get probed?
Hi!
According to n900 dts, twl4030-bci (aka charger) should be included.
(But it does not seem to do anything useful on n900. I was hoping for
measurement of input voltage, but .. no.)
Any ideas why the patch below is needed?
Signed-off-by: Pavel Machek
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index d35b83e..96bbbe9 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -714,6 +722,7 @@ static const struct of_device_id twl_bci_of_match[] = {
MODULE_DEVICE_TABLE(of, twl_bci_of_match);
static struct platform_driver twl4030_bci_driver = {
+ .probe = twl4030_bci_probe,
.driver = {
.name = "twl4030_bci",
.of_match_table = of_match_ptr(twl_bci_of_match),
@@ -721,7 +730,7 @@ static struct platform_driver twl4030_bci_driver = {
.remove = __exit_p(twl4030_bci_remove),
};
-module_platform_driver_probe(twl4030_bci_driver, twl4030_bci_probe);
+module_platform_driver(twl4030_bci_driver);
MODULE_AUTHOR("Gražvydas Ignotas");
MODULE_DESCRIPTION("TWL4030 Battery Charger Interface driver");
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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
