s3c24xx: iPAQ rx1950 series

PATCH Superseded Vasily Khoruzhick 3 participants 15 messages Jul 10, 2010 – Jul 13, 2010

Subsystems (3)

Arm (32-bit) Arm sub-architectures LED

lore

Share & tools

lore

Vasily Khoruzhick

author

2010-07-10 16:57 UTC #0 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

This patch series adds more support for iPAQ rx1950 PDA to linux:
1. LEDs driver -- it controls blue, green and red LEDs on rx1950
2. Battery driver -- adds ability to monitor and charge battery. This driver is suitable for H1940 PDA aswell (just need to write some machine specific callbacks and get voltage LUTs)

v2: removed ac registration from s3c_adc_battery driver, use pda_power instead for ac support.

P.S. I prefer to keep own LED triggers for s3c_adc_battery as generic power supply triggers do not support LED_HALF brightness (on h1940/rx1950 it's used for blink) and I want to keep same LEDs behavior as in WinMo.

Vasily Khoruzhick

author

2010-07-10 16:57 UTC #1 lore raw

PATCH v2 1/3 rx1950: add rx1950 LEDs driver

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-s3c2440/mach-rx1950.c |    6 +
 drivers/leds/Kconfig                |    6 +
 drivers/leds/Makefile               |    1 +
 drivers/leds/leds-rx1950.c          |  206 +++++++++++++++++++++++++++++++++++
 4 files changed, 219 insertions(+), 0 deletions(-)
 create mode 100644 drivers/leds/leds-rx1950.c

arch/arm/mach-s3c2440/mach-rx1950.c +6 -0

index 8603b57..55b806a 100644
@@ -126,6 +126,11 @@ static struct s3c2410fb_display rx1950_display = {
 
 };
 
+static struct platform_device rx1950_device_leds = {
+	.name             = "rx1950-leds",
+	.id               = -1,
+};
+
 static struct s3c2410fb_mach_info rx1950_lcd_cfg = {
 	.displays = &rx1950_display,
 	.num_displays = 1,

@@ -502,6 +507,7 @@ static struct platform_device *rx1950_devices[] __initdata = {
 	&s3c_device_timer[1],
 	&rx1950_backlight,
 	&rx1950_device_gpiokeys,
+	&rx1950_device_leds,
 };
 
 static struct clk *rx1950_clocks[] __initdata = {

drivers/leds/Kconfig +6 -0

index 81bf25e..f986825 100644
@@ -102,6 +102,12 @@ config LEDS_H1940
 	help
 	  This option enables support for the LEDs on the h1940.
 
+config LEDS_RX1950
+	tristate "LED Support for iPAQ RX1950 device"
+	depends on MACH_RX1950
+	help
+	  This option enables support for the LEDs on the rx1950.
+
 config LEDS_COBALT_QUBE
 	tristate "LED Support for the Cobalt Qube series front LED"
 	depends on MIPS_COBALT

drivers/leds/Makefile +1 -0

index 2493de4..faa0d5d 100644
@@ -17,6 +17,7 @@ obj-$(CONFIG_LEDS_NET5501)		+= leds-net5501.o
 obj-$(CONFIG_LEDS_WRAP)			+= leds-wrap.o
 obj-$(CONFIG_LEDS_ALIX2)		+= leds-alix2.o
 obj-$(CONFIG_LEDS_H1940)		+= leds-h1940.o
+obj-$(CONFIG_LEDS_RX1950)		+= leds-rx1950.o
 obj-$(CONFIG_LEDS_COBALT_QUBE)		+= leds-cobalt-qube.o
 obj-$(CONFIG_LEDS_COBALT_RAQ)		+= leds-cobalt-raq.o
 obj-$(CONFIG_LEDS_SUNFIRE)		+= leds-sunfire.o

drivers/leds/leds-rx1950.c new file +206 -0

206 lines not on this page · raw message

Signature · 1 line

1.7.1

Vasily Khoruzhick

author

2010-07-10 16:57 UTC #2 lore raw

PATCH v2 2/3 Add s3c-adc-battery driver

In reply to Vasily Khoruzhick

s3c-adc-battery is driver for monitoring
and charging battery on iPAQ H1930/H1940/RX1950.
It depends on s3c-adc driver to get battery voltage and current.

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 drivers/power/Kconfig           |    6 +
 drivers/power/Makefile          |    1 +
 drivers/power/s3c_adc_battery.c |  431 +++++++++++++++++++++++++++++++++++++++
 include/linux/s3c_adc_battery.h |   36 ++++
 4 files changed, 474 insertions(+), 0 deletions(-)
 create mode 100644 drivers/power/s3c_adc_battery.c
 create mode 100644 include/linux/s3c_adc_battery.h

drivers/power/Kconfig +6 -0

index 8e9ba17..645baa5 100644
@@ -136,6 +136,12 @@ config BATTERY_Z2
 	help
 	  Say Y to include support for the battery on the Zipit Z2.
 
+config BATTERY_S3C_ADC
+	tristate "Battery driver for Samsung ADC based monitoring"
+	depends on S3C_ADC
+	help
+	  Say Y here to enable support for iPAQ h1930/h1940/rx1950 battery
+
 config CHARGER_PCF50633
 	tristate "NXP PCF50633 MBC"
 	depends on MFD_PCF50633

drivers/power/Makefile +1 -0

index 0005080..166bcbf 100644
@@ -33,4 +33,5 @@ obj-$(CONFIG_BATTERY_BQ27x00)	+= bq27x00_battery.o
 obj-$(CONFIG_BATTERY_DA9030)	+= da9030_battery.o
 obj-$(CONFIG_BATTERY_MAX17040)	+= max17040_battery.o
 obj-$(CONFIG_BATTERY_Z2)	+= z2_battery.o
+obj-$(CONFIG_BATTERY_S3C_ADC)	+= s3c_adc_battery.o
 obj-$(CONFIG_CHARGER_PCF50633)	+= pcf50633-charger.o

drivers/power/s3c_adc_battery.c new file +431 -0

431 lines not on this page · raw message

include/linux/s3c_adc_battery.h new file +36 -0

new file mode 100644
index 0000000..624d29a
@@ -0,0 +1,36 @@
+#ifndef _S3C_ADC_BATTERY_H
+#define _S3C_ADC_BATTERY_H
+
+struct s3c_adc_bat_thresh {
+	int volt; /* mV */
+	int cur; /* mA */
+	int level; /* percent */
+};
+
+struct s3c_adc_bat_pdata {
+	int (*init)(void);
+	void (*exit)(void);
+	void (*enable_charger)(void);
+	void (*disable_charger)(void);
+
+	unsigned int gpio_charge_finished;
+
+	const struct s3c_adc_bat_thresh *lut_noac;
+	unsigned int lut_noac_cnt;
+	const struct s3c_adc_bat_thresh *lut_acin;
+	unsigned int lut_acin_cnt;
+
+	const unsigned int volt_channel;
+	const unsigned int current_channel;
+	const unsigned int backup_volt_channel;
+
+	const unsigned int volt_mult;
+	const unsigned int current_mult;
+	const unsigned int backup_volt_mult;
+	const unsigned int internal_impedance;
+
+	const unsigned int backup_volt_max;
+	const unsigned int backup_volt_min;
+};
+
+#endif

Signature · 1 line

1.7.1

Anton Vorontsov

2010-07-13 18:27 UTC #3 lore raw

PATCH v2 2/3 Add s3c-adc-battery driver

Quoted 5 lines · Vasily Khoruzhick

s3c-adc-battery is driver for monitoring
and charging battery on iPAQ H1930/H1940/RX1950.
It depends on s3c-adc driver to get battery voltage and current.
Signed-off-by Vasily Khoruzhick <[email protected]>

[...]

drivers/power/s3c_adc_battery.c line 61

Quoted 9 lines

drivers/power/s3c_adc_battery.c new file +9 -0

+static enum power_supply_property s3c_adc_backup_bat_props[] = {
+	POWER_SUPPLY_PROP_VOLTAGE_NOW,
+	POWER_SUPPLY_PROP_VOLTAGE_MIN,
+	POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
+};
+
+static int s3c_adc_backup_bat_get_property(struct power_supply *psy,
+				enum power_supply_property psp,
+				union power_supply_propval *val);

Do you really need this forward decl? I think you can just rearrange the code to avoid it.

Quoted 13 lines

drivers/power/s3c_adc_battery.c new file +13 -0

+static struct s3c_adc_bat backup_bat = {
+	.psy = {
+		.name		= "backup-battery",
+		.type		= POWER_SUPPLY_TYPE_BATTERY,
+		.properties	= s3c_adc_backup_bat_props,
+		.num_properties = ARRAY_SIZE(s3c_adc_backup_bat_props),
+		.get_property	= s3c_adc_backup_bat_get_property,
+		.use_for_apm	= 1,
+	},
+};
+
+static enum power_supply_property s3c_adc_main_bat_props[] = {
+	POWER_SUPPLY_PROP_STATUS,

drivers/power/s3c_adc_battery.c line 85

Quoted 10 lines

drivers/power/s3c_adc_battery.c new file +10 -0

+	POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
+	POWER_SUPPLY_PROP_CHARGE_EMPTY_DESIGN,
+	POWER_SUPPLY_PROP_CHARGE_NOW,
+	POWER_SUPPLY_PROP_VOLTAGE_NOW,
+	POWER_SUPPLY_PROP_CURRENT_NOW,
+};
+
+static int s3c_adc_bat_get_property(struct power_supply *psy,
+				enum power_supply_property psp,
+				union power_supply_propval *val);

Ditto.

[...]

drivers/power/s3c_adc_battery.c line 141

Quoted 8 lines

drivers/power/s3c_adc_battery.c new file +8 -0

+static void s3c_adc_bat_work(struct work_struct *work)
+{
+	struct s3c_adc_bat *bat = &main_bat;
+	int is_charged;
+	int is_plugged;
+	static int was_plugged;
+
+	is_plugged = power_supply_am_i_supplied(&bat->psy);

Nice, isn't it? :-)

Signature · 3 lines

Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

Vasily Khoruzhick

author

2010-07-10 16:57 UTC #4 lore raw

PATCH v2 3/3 rx1950: add battery support

In reply to Vasily Khoruzhick

Signed-off-by Vasily Khoruzhick <[email protected]>

---
 arch/arm/mach-s3c2440/Kconfig       |    3 +
 arch/arm/mach-s3c2440/mach-rx1950.c |  160 +++++++++++++++++++++++++++++++++++
 2 files changed, 163 insertions(+), 0 deletions(-)

arch/arm/mach-s3c2440/Kconfig +3 -0

index cd8e7de..9b6b026 100644
@@ -198,6 +198,9 @@ config MACH_RX1950
 	select S3C_DEV_NAND
 	select S3C2410_IOTIMING if S3C2440_CPUFREQ
 	select S3C2440_XTAL_16934400
+	select S3C_ADC
+	select PDA_POWER
+	select BATTERY_S3C_ADC
 	help
 	   Say Y here if you're using HP iPAQ rx1950

arch/arm/mach-s3c2440/mach-rx1950.c +160 -0

180 lines not on this page · raw message

Signature · 1 line

1.7.1

Vasily Khoruzhick

author

2010-07-12 13:28 UTC #5 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

In reply to Vasily Khoruzhick

? ????????? ?? 10 ???? 2010 19:57:46 ????? Vasily Khoruzhick ???????:

Quoted 6 lines

This patch series adds more support for iPAQ rx1950 PDA to linux:
1. LEDs driver -- it controls blue, green and red LEDs on rx1950
2. Battery driver -- adds ability to monitor and charge battery. This driver is suitable for H1940 PDA aswell (just need to write some machine specific callbacks and get voltage LUTs)

Quoted 7 lines

v2: removed ac registration from s3c_adc_battery driver, use pda_power instead for ac support.
P.S. I prefer to keep own LED triggers for s3c_adc_battery as generic power supply triggers do not support LED_HALF brightness (on h1940/rx1950 it's used for blink) and I want to keep same LEDs behavior as in WinMo.

Ping :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100712/722bcf65/attachment.sig>

Anton Vorontsov

2010-07-13 15:13 UTC #6 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

In reply to Vasily Khoruzhick

Quoted 6 lines · Vasily Khoruzhick

This patch series adds more support for iPAQ rx1950 PDA to linux:
1. LEDs driver -- it controls blue, green and red LEDs on rx1950
2. Battery driver -- adds ability to monitor and charge battery. This driver is suitable for H1940 PDA aswell (just need to write some machine specific callbacks and get voltage LUTs)

Quoted 7 lines

v2: removed ac registration from s3c_adc_battery driver, use pda_power instead for ac support.
P.S. I prefer to keep own LED triggers for s3c_adc_battery as generic power supply triggers do not support LED_HALF brightness (on h1940/rx1950 it's used for blink) and I want to keep same LEDs behavior as in WinMo.

No, please. Factor out LED triggers addition into a separate patch and we will discuss* it. That way it won't block this driver merge.

Thanks,

* IIRC, using LED_HALF for blinking is wrong, see drivers/leds/leds-pwm.c for a preferred approach.

Signature · 3 lines

Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

Vasily Khoruzhick

author

2010-07-13 15:45 UTC #7 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

? ????????? ?? 13 ???? 2010 18:13:10 ????? Anton Vorontsov ???????:

Quoted 2 lines

No, please. Factor out LED triggers addition into a separate patch and we will discuss* it. That way it won't block this driver merge.

I'm not in hurry :) it's just my hobby, and I really don't care _when_ this driver will be merged. But I want it to be merged with all functionality (getting status/charging/LEDs).

Quoted 2 lines

* IIRC, using LED_HALF for blinking is wrong, see drivers/leds/leds-pwm.c for a preferred approach.

Then it needs complex trigger, so anyway generic power supply simple triggers do not fit in my case. Btw, some LEDs drivers in mainline kernels use LED_HALF for blinking, i.e. leds-pca955x.c and leds-h1940.c.

Regards
Vasily
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100713/70e2cf95/attachment.sig>

Mark Brown

2010-07-13 15:58 UTC #8 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

Quoted 6 lines · Vasily Khoruzhick

Quoted 2 lines
* IIRC, using LED_HALF for blinking is wrong, see drivers/leds/leds-pwm.c for a preferred approach.
Then it needs complex trigger, so anyway generic power supply simple triggers do not fit in my case. Btw, some LEDs drivers in mainline kernels use LED_HALF for blinking, i.e. leds-pca955x.c and leds-h1940.c.

Are you sure that those drivers are actually blinking? The code makes it look like at least pca955x is using PWM to provide brightness control rather than actually blinking at a human visible rate.

Vasily Khoruzhick

author

2010-07-13 17:05 UTC #9 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

? ????????? ?? 13 ???? 2010 18:58:12 ????? Mark Brown ???????:

Quoted 3 lines

Are you sure that those drivers are actually blinking? The code makes it look like at least pca955x is using PWM to provide brightness control rather than actually blinking at a human visible rate.

As for h1940 driver - I'm sure,
for pca955x I was wrong, it just sets brightness (it uses PWM0 for LED_HALF value).

Btw, does any driver in kernel uses ledtrig-timer? I don't understand how to use it from driver :\

One more thing: on rx1950 (and on h1940) it's impossible to set blink duty/period, is it really necessary to define blink_set callback in LEDs driver instead of blinking on LED_HALF?

Mark Brown

2010-07-13 18:03 UTC #10 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

Quoted 3 lines · Vasily Khoruzhick

One more thing: on rx1950 (and on h1940) it's impossible to set blink duty/period, is it really necessary to define blink_set callback in LEDs driver instead of blinking on LED_HALF?

If an application tries to set the LED brightness but the LED actually starts blinking that sounds bad...

Vasily Khoruzhick

author

2010-07-13 18:29 UTC #11 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

? ????????? ?? 13 ???? 2010 21:03:03 ????? Mark Brown ???????:

Quoted 2 lines

If an application tries to set the LED brightness but the LED actually starts blinking that sounds bad...

Yeah, but how some driver from kernel should make LED blink when LED driver
defines blink_set callback?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100713/3cec6b00/attachment.sig>

Mark Brown

2010-07-13 20:08 UTC #12 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

Quoted 6 lines · Vasily Khoruzhick

? ????????? ?? 13 ???? 2010 21:03:03 ????? Mark Brown ???????:
Quoted 2 lines
If an application tries to set the LED brightness but the LED actually starts blinking that sounds bad...
Yeah, but how some driver from kernel should make LED blink when LED driver defines blink_set callback?

I don't know off the top of by head but if that's not currently possible then surely the way forward is to add this new functionality rather than introduce breakage?

Vasily Khoruzhick

author

2010-07-13 20:11 UTC #13 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

? ????????? ?? 13 ???? 2010 23:08:32 ????? Mark Brown ???????:

Quoted 3 lines

I don't know off the top of by head but if that's not currently possible then surely the way forward is to add this new functionality rather than introduce breakage?

Actually, I'm asking if there's such functionality, because I can't find it :( -------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100713/1f23f72e/attachment.sig>

Anton Vorontsov

2010-07-13 16:27 UTC #14 lore raw

v2 cover s3c24xx: iPAQ rx1950 series

In reply to Vasily Khoruzhick

Quoted 6 lines · Vasily Khoruzhick

? ????????? ?? 13 ???? 2010 18:13:10 ????? Anton Vorontsov ???????:
Quoted 2 lines
No, please. Factor out LED triggers addition into a separate patch and we will discuss* it. That way it won't block this driver merge.
I'm not in hurry :)

But you should. Months later you'll not have time/energy to continue, and if you not merge your patches ASAP, then all the great work that you did will quickly become outdated (like most of handhelds.org projects nowadays. ;-)

Quoted 2 lines

But I want it to be merged with all functionality
(getting status/charging/LEDs).

Sure thing, in the end it will have all the functionality.

But let's do one thing at a time? Just factor out the LEDs stuff into a separate patch, and we'll think how to deal with these LEDs.

Thanks,

Signature · 3 lines

Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2