2013-09-08 08:51:07

by Pali Rohár

[permalink] [raw]
Subject: [PATCH 0/4] Add support for charging battery in Nokia RX-51

This patch series finally bringing support for charging battery on
Nokia N900 (RX-51) without any proprietary Nokia bits in userspace.

Pali Rohár (4):
usb: musb: Call atomic_notifier_call_chain when status is changed
power: isp1704_charger: Fix driver to work with changes introduced in
v3.5
power: isp1704_charger: Add callback function set_current
RX-51: Add platform function and data for bq24150a charger

arch/arm/mach-omap2/board-rx51-peripherals.c | 56 +++++++++++++-
drivers/power/isp1704_charger.c | 107 ++++++++++++++------------
drivers/usb/musb/omap2430.c | 3 +
drivers/usb/phy/phy-twl4030-usb.c | 2 +
include/linux/power/isp1704_charger.h | 1 +
5 files changed, 117 insertions(+), 52 deletions(-)

--
1.7.10.4


2013-09-08 08:51:16

by Pali Rohár

[permalink] [raw]
Subject: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.

So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting bogus values to userspace and also to board
platform data functions. Without proper data charger drivers trying to
charge battery also when charger is disconnected or do not start charging
when wallcharger connects.

Atomic notifier in musb driver was used before v3.5 and was replaced with
omap mailbox. This patch adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.

Signed-off-by: Pali Rohár <[email protected]>
---
drivers/usb/musb/omap2430.c | 3 +++
drivers/usb/phy/phy-twl4030-usb.c | 2 ++
2 files changed, 5 insertions(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..5c40252 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
default:
dev_dbg(dev, "ID float\n");
}
+
+ atomic_notifier_call_chain(&musb->xceiv->notifier,
+ musb->xceiv->last_event, NULL);
}


diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
if (device_create_file(&pdev->dev, &dev_attr_vbus))
dev_warn(&pdev->dev, "could not create sysfs file\n");

+ ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
/* Our job is to use irqs and status from the power module
* to keep the transceiver disabled when nothing's connected.
*
--
1.7.10.4

2013-09-08 08:51:25

by Pali Rohár

[permalink] [raw]
Subject: [PATCH 2/4] power: isp1704_charger: Fix driver to work with changes introduced in v3.5

* omap musb driver does not report USB_EVENT_ENUMERATED event anymore
* omap musb driver reporting USB_EVENT_VBUS when charger is connected
* read last event from phy->last_event (instead from ulpi register)
* do not call wall charger detection more times

Signed-off-by: Pali Rohár <[email protected]>
---
drivers/power/isp1704_charger.c | 91 +++++++++++++++++----------------------
1 file changed, 40 insertions(+), 51 deletions(-)

diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index fc04d19..f726cb6 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -2,6 +2,7 @@
* ISP1704 USB Charger Detection driver
*
* Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2012 - 2013 Pali Rohár <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -65,10 +66,6 @@ struct isp1704_charger {
unsigned present:1;
unsigned online:1;
unsigned current_max;
-
- /* temp storage variables */
- unsigned long event;
- unsigned max_power;
};

static inline int isp1704_read(struct isp1704_charger *isp, u32 reg)
@@ -231,56 +228,59 @@ static inline int isp1704_charger_detect(struct isp1704_charger *isp)
return ret;
}

+static inline int isp1704_charger_detect_dcp(struct isp1704_charger *isp)
+{
+ if (isp1704_charger_detect(isp) &&
+ isp1704_charger_type(isp) == POWER_SUPPLY_TYPE_USB_DCP)
+ return true;
+ else
+ return false;
+}
+
static void isp1704_charger_work(struct work_struct *data)
{
- int detect;
- unsigned long event;
- unsigned power;
struct isp1704_charger *isp =
container_of(data, struct isp1704_charger, work);
static DEFINE_MUTEX(lock);

- event = isp->event;
- power = isp->max_power;
-
mutex_lock(&lock);

- if (event != USB_EVENT_NONE)
- isp1704_charger_set_power(isp, 1);
-
- switch (event) {
+ switch (isp->phy->last_event) {
case USB_EVENT_VBUS:
- isp->online = true;
+ /* do not call wall charger detection more times */
+ if (!isp->present) {
+ isp->online = true;
+ isp->present = 1;
+ isp1704_charger_set_power(isp, 1);
+
+ /* detect wall charger */
+ if (isp1704_charger_detect_dcp(isp)) {
+ isp->psy.type = POWER_SUPPLY_TYPE_USB_DCP;
+ isp->current_max = 1800;
+ } else {
+ isp->psy.type = POWER_SUPPLY_TYPE_USB;
+ isp->current_max = 500;
+ }

- /* detect charger */
- detect = isp1704_charger_detect(isp);
-
- if (detect) {
- isp->present = detect;
- isp->psy.type = isp1704_charger_type(isp);
+ /* enable data pullups */
+ if (isp->phy->otg->gadget)
+ usb_gadget_connect(isp->phy->otg->gadget);
}

- switch (isp->psy.type) {
- case POWER_SUPPLY_TYPE_USB_DCP:
- isp->current_max = 1800;
- break;
- case POWER_SUPPLY_TYPE_USB_CDP:
+ if (isp->psy.type != POWER_SUPPLY_TYPE_USB_DCP) {
/*
* Only 500mA here or high speed chirp
* handshaking may break
*/
- isp->current_max = 500;
- /* FALLTHROUGH */
- case POWER_SUPPLY_TYPE_USB:
- default:
- /* enable data pullups */
- if (isp->phy->otg->gadget)
- usb_gadget_connect(isp->phy->otg->gadget);
+ if (isp->current_max > 500)
+ isp->current_max = 500;
+
+ if (isp->current_max > 100)
+ isp->psy.type = POWER_SUPPLY_TYPE_USB_CDP;
}
break;
case USB_EVENT_NONE:
isp->online = false;
- isp->current_max = 0;
isp->present = 0;
isp->current_max = 0;
isp->psy.type = POWER_SUPPLY_TYPE_USB;
@@ -298,12 +298,6 @@ static void isp1704_charger_work(struct work_struct *data)

isp1704_charger_set_power(isp, 0);
break;
- case USB_EVENT_ENUMERATED:
- if (isp->present)
- isp->current_max = 1800;
- else
- isp->current_max = power;
- break;
default:
goto out;
}
@@ -314,16 +308,11 @@ out:
}

static int isp1704_notifier_call(struct notifier_block *nb,
- unsigned long event, void *power)
+ unsigned long val, void *v)
{
struct isp1704_charger *isp =
container_of(nb, struct isp1704_charger, nb);

- isp->event = event;
-
- if (power)
- isp->max_power = *((unsigned *)power);
-
schedule_work(&isp->work);

return NOTIFY_OK;
@@ -462,13 +451,13 @@ static int isp1704_charger_probe(struct platform_device *pdev)
if (isp->phy->otg->gadget)
usb_gadget_disconnect(isp->phy->otg->gadget);

+ if (isp->phy->last_event == USB_EVENT_NONE)
+ isp1704_charger_set_power(isp, 0);
+
/* Detect charger if VBUS is valid (the cable was already plugged). */
- ret = isp1704_read(isp, ULPI_USB_INT_STS);
- isp1704_charger_set_power(isp, 0);
- if ((ret & ULPI_INT_VBUS_VALID) && !isp->phy->otg->default_a) {
- isp->event = USB_EVENT_VBUS;
+ if (isp->phy->last_event == USB_EVENT_VBUS &&
+ !isp->phy->otg->default_a)
schedule_work(&isp->work);
- }

return 0;
fail2:
--
1.7.10.4

2013-09-08 08:51:32

by Pali Rohár

[permalink] [raw]
Subject: [PATCH 3/4] power: isp1704_charger: Add callback function set_current

This patch add callback function set_current to platform data.
Driver will call this function when isp1704 change current
and board provided this callback funtion in platform data.

This patch is needed for Nokia RX-51 to tell bq2415x charging
chip about connected wallcharger events.

Signed-off-by: Pali Rohár <[email protected]>
---
drivers/power/isp1704_charger.c | 16 ++++++++++++++++
include/linux/power/isp1704_charger.h | 1 +
2 files changed, 17 insertions(+)

diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index f726cb6..4f20a1a 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -91,6 +91,18 @@ static void isp1704_charger_set_power(struct isp1704_charger *isp, bool on)
}

/*
+ * Set charger current from isp1704 if a function for it
+ * has been provided with platform data.
+ */
+static void isp1704_charger_set_current(struct isp1704_charger *isp, int mA)
+{
+ struct isp1704_charger_data *board = isp->dev->platform_data;
+
+ if (board && board->set_current)
+ board->set_current(mA);
+}
+
+/*
* Determine is the charging port DCP (dedicated charger) or CDP (Host/HUB
* chargers).
*
@@ -257,6 +269,7 @@ static void isp1704_charger_work(struct work_struct *data)
if (isp1704_charger_detect_dcp(isp)) {
isp->psy.type = POWER_SUPPLY_TYPE_USB_DCP;
isp->current_max = 1800;
+ isp1704_charger_set_current(isp, 1800);
} else {
isp->psy.type = POWER_SUPPLY_TYPE_USB;
isp->current_max = 500;
@@ -277,6 +290,8 @@ static void isp1704_charger_work(struct work_struct *data)

if (isp->current_max > 100)
isp->psy.type = POWER_SUPPLY_TYPE_USB_CDP;
+
+ isp1704_charger_set_current(isp, isp->current_max);
}
break;
case USB_EVENT_NONE:
@@ -297,6 +312,7 @@ static void isp1704_charger_work(struct work_struct *data)
usb_gadget_disconnect(isp->phy->otg->gadget);

isp1704_charger_set_power(isp, 0);
+ isp1704_charger_set_current(isp, 0);
break;
default:
goto out;
diff --git a/include/linux/power/isp1704_charger.h b/include/linux/power/isp1704_charger.h
index 68096a6..d154b02 100644
--- a/include/linux/power/isp1704_charger.h
+++ b/include/linux/power/isp1704_charger.h
@@ -24,6 +24,7 @@

struct isp1704_charger_data {
void (*set_power)(bool on);
+ void (*set_current)(int mA);
};

#endif
--
1.7.10.4

2013-09-08 08:51:42

by Pali Rohár

[permalink] [raw]
Subject: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

This patch will register bq24150a charger in RX-51 board data.
Patch also adding platform function between isp1704 and bq2415x
drivers for detecting charger type.

So finally charging battery on Nokia N900 (RX-51) working
automatically without any proprietary Nokia bits in userspace.

Signed-off-by: Pali Rohár <[email protected]>
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 56 +++++++++++++++++++++++++-
1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9c2dd10..a993ffe 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -25,6 +25,7 @@
#include <linux/gpio_keys.h>
#include <linux/mmc/host.h>
#include <linux/power/isp1704_charger.h>
+#include <linux/power/bq2415x_charger.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <linux/platform_data/mtd-onenand-omap2.h>

@@ -270,6 +271,44 @@ static struct platform_device rx51_battery_device = {
.id = -1,
};

+static enum bq2415x_mode rx51_charger_mode = BQ2415X_MODE_OFF;
+static void *rx51_charger_hook_data;
+static void (*rx51_charger_hook)(enum bq2415x_mode mode, void *data);
+
+static int rx51_charger_set_hook(
+ void (*hook)(enum bq2415x_mode mode, void *data), void *data)
+{
+ rx51_charger_hook = hook;
+ rx51_charger_hook_data = data;
+ if (rx51_charger_hook)
+ rx51_charger_hook(rx51_charger_mode, rx51_charger_hook_data);
+ return 1;
+}
+
+static void rx51_charger_set_current(int mA)
+{
+ enum bq2415x_mode mode;
+
+ pr_info("RX-51: Charger current limit is %d mA\n", mA);
+
+ if (mA == 0)
+ mode = BQ2415X_MODE_OFF;
+ else if (mA < 500)
+ mode = BQ2415X_MODE_NONE;
+ else if (mA < 1800)
+ mode = BQ2415X_MODE_HOST_CHARGER;
+ else
+ mode = BQ2415X_MODE_DEDICATED_CHARGER;
+
+ if (rx51_charger_mode == mode)
+ return;
+
+ rx51_charger_mode = mode;
+
+ if (rx51_charger_hook)
+ rx51_charger_hook(rx51_charger_mode, rx51_charger_hook_data);
+}
+
static void rx51_charger_set_power(bool on)
{
gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
@@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool on)

static struct isp1704_charger_data rx51_charger_data = {
.set_power = rx51_charger_set_power,
+ .set_current = rx51_charger_set_current,
};

static struct platform_device rx51_charger_device = {
@@ -1017,6 +1057,16 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
.gpio_reset = 60,
};

+static struct bq2415x_platform_data rx51_bq24150a_platform_data = {
+ .current_limit = 100, /* mA */
+ .weak_battery_voltage = 3400, /* mV */
+ .battery_regulation_voltage = 4200, /* mV */
+ .charge_current = 650, /* mA */
+ .termination_current = 100, /* mA */
+ .resistor_sense = 68, /* m ohm */
+ .set_mode_hook = &rx51_charger_set_hook,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),
@@ -1044,7 +1094,11 @@ static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO("tpa6130a2", 0x60),
.platform_data = &rx51_tpa6130a2_data,
- }
+ },
+ {
+ I2C_BOARD_INFO("bq24150a", 0x6b),
+ .platform_data = &rx51_bq24150a_platform_data,
+ },
};

static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_3[] = {
--
1.7.10.4

2013-09-09 13:39:30

by Sebastian Reichel

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

Hi Pali,

On Sun, Sep 08, 2013 at 10:50:39AM +0200, Pali Roh?r wrote:
> This patch will register bq24150a charger in RX-51 board data.
> Patch also adding platform function between isp1704 and bq2415x
> drivers for detecting charger type.
>
> So finally charging battery on Nokia N900 (RX-51) working
> automatically without any proprietary Nokia bits in userspace.

cool :)

> index 9c2dd10..a993ffe 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c

AFAIK platform code for omap3 based boards is supposed to be removed
in the near future [0]. Device Tree does not support the glue layer, so
probably a small rx51 specific driver is needed.

[0] https://lkml.org/lkml/2013/8/12/70

-- Sebastian

Attachments:
(No filename) (760.00 B)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-14 09:38:50

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 0/4] Add support for charging battery in Nokia RX-51

On Sunday 08 September 2013 10:50:35 Pali Rohár wrote:
> This patch series finally bringing support for charging
> battery on Nokia N900 (RX-51) without any proprietary Nokia
> bits in userspace.
>
> Pali Rohár (4):
> usb: musb: Call atomic_notifier_call_chain when status is
> changed power: isp1704_charger: Fix driver to work with
> changes introduced in v3.5
> power: isp1704_charger: Add callback function set_current
> RX-51: Add platform function and data for bq24150a charger
>
> arch/arm/mach-omap2/board-rx51-peripherals.c | 56
> +++++++++++++- drivers/power/isp1704_charger.c |
> 107 ++++++++++++++------------ drivers/usb/musb/omap2430.c
> | 3 + drivers/usb/phy/phy-twl4030-usb.c
> | 2 + include/linux/power/isp1704_charger.h
> | 1 + 5 files changed, 117 insertions(+), 52 deletions(-)

Hello, can you review this patch series?

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-17 15:51:31

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
> if (device_create_file(&pdev->dev, &dev_attr_vbus))
> dev_warn(&pdev->dev, "could not create sysfs file\n");
>
> + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);

BTW, this is a bugfix, send separately.

--
balbi

Attachments:
(No filename) (565.00 B)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-17 15:51:56

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> More power supply drivers depends on vbus events and without it they not
> working. Power supply drivers using usb_register_notifier, so to deliver
> events it is needed to call atomic_notifier_call_chain.
>
> So without atomic notifier power supply driver isp1704 not retrieving
> vbus status and reporting bogus values to userspace and also to board
> platform data functions. Without proper data charger drivers trying to
> charge battery also when charger is disconnected or do not start charging
> when wallcharger connects.
>
> Atomic notifier in musb driver was used before v3.5 and was replaced with
> omap mailbox. This patch adding atomic_notifier_call_chain call from
> function omap_musb_set_mailbox.
>
> Signed-off-by: Pali Roh?r <[email protected]>
> ---
> drivers/usb/musb/omap2430.c | 3 +++
> drivers/usb/phy/phy-twl4030-usb.c | 2 ++
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index f44e8b5..5c40252 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
> default:
> dev_dbg(dev, "ID float\n");
> }
> +
> + atomic_notifier_call_chain(&musb->xceiv->notifier,
> + musb->xceiv->last_event, NULL);

let's add a wrapper for this:

static inline int usb_phy_notify(struct usb phy *x, unsigned val, void *v)
{
return atomic_notifier_call_chain(&x->notifier, val, v);
}

--
balbi

Attachments:
(No filename) (1.52 kB)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-17 16:05:21

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Tuesday 17 September 2013 17:48:59 you wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > More power supply drivers depends on vbus events and without
> > it they not working. Power supply drivers using
> > usb_register_notifier, so to deliver events it is needed to
> > call atomic_notifier_call_chain.
> >
> > So without atomic notifier power supply driver isp1704 not
> > retrieving vbus status and reporting bogus values to
> > userspace and also to board platform data functions.
> > Without proper data charger drivers trying to charge
> > battery also when charger is disconnected or do not start
> > charging when wallcharger connects.
> >
> > Atomic notifier in musb driver was used before v3.5 and was
> > replaced with omap mailbox. This patch adding
> > atomic_notifier_call_chain call from function
> > omap_musb_set_mailbox.
> >
> > Signed-off-by: Pali Rohár <[email protected]>
> > ---
> >
> > drivers/usb/musb/omap2430.c | 3 +++
> > drivers/usb/phy/phy-twl4030-usb.c | 2 ++
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/drivers/usb/musb/omap2430.c
> > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > --- a/drivers/usb/musb/omap2430.c
> > +++ b/drivers/usb/musb/omap2430.c
> > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > omap2430_glue *glue)
> >
> > default:
> > dev_dbg(dev, "ID float\n");
> >
> > }
> >
> > +
> > + atomic_notifier_call_chain(&musb->xceiv->notifier,
> > + musb->xceiv->last_event, NULL);
>
> let's add a wrapper for this:
>
> static inline int usb_phy_notify(struct usb phy *x, unsigned
> val, void *v) {
> return atomic_notifier_call_chain(&x->notifier, val, v);
> }

Where to add this wrapper? To omap2430.c? or some include file?

On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev)
> >
> > if (device_create_file(&pdev->dev, &dev_attr_vbus))
> >
> > dev_warn(&pdev->dev, "could not create sysfs file\n");
> >
> > + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
>
> BTW, this is a bugfix, send separately.

What to send separately?

This full patch 1/4 is bugfix. And I did not understand what you
want. Maybe it could be easier for you to apply this small 3+2
lines patch how you need.

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-17 16:10:41

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> On Tuesday 17 September 2013 17:48:59 you wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > More power supply drivers depends on vbus events and without
> > > it they not working. Power supply drivers using
> > > usb_register_notifier, so to deliver events it is needed to
> > > call atomic_notifier_call_chain.
> > >
> > > So without atomic notifier power supply driver isp1704 not
> > > retrieving vbus status and reporting bogus values to
> > > userspace and also to board platform data functions.
> > > Without proper data charger drivers trying to charge
> > > battery also when charger is disconnected or do not start
> > > charging when wallcharger connects.
> > >
> > > Atomic notifier in musb driver was used before v3.5 and was
> > > replaced with omap mailbox. This patch adding
> > > atomic_notifier_call_chain call from function
> > > omap_musb_set_mailbox.
> > >
> > > Signed-off-by: Pali Roh?r <[email protected]>
> > > ---
> > >
> > > drivers/usb/musb/omap2430.c | 3 +++
> > > drivers/usb/phy/phy-twl4030-usb.c | 2 ++
> > > 2 files changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/usb/musb/omap2430.c
> > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > > --- a/drivers/usb/musb/omap2430.c
> > > +++ b/drivers/usb/musb/omap2430.c
> > > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > > omap2430_glue *glue)
> > >
> > > default:
> > > dev_dbg(dev, "ID float\n");
> > >
> > > }
> > >
> > > +
> > > + atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > + musb->xceiv->last_event, NULL);
> >
> > let's add a wrapper for this:
> >
> > static inline int usb_phy_notify(struct usb phy *x, unsigned
> > val, void *v) {
> > return atomic_notifier_call_chain(&x->notifier, val, v);
> > }
>
> Where to add this wrapper? To omap2430.c? or some include file?

<linux/usb/phy.h>

> On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > 100644
> > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > platform_device *pdev)
> > >
> > > if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > >
> > > dev_warn(&pdev->dev, "could not create sysfs file\n");
> > >
> > > + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> >
> > BTW, this is a bugfix, send separately.
>
> What to send separately?
>
> This full patch 1/4 is bugfix. And I did not understand what you
> want. Maybe it could be easier for you to apply this small 3+2
> lines patch how you need.

This hunk here (initializaing notifier head) is a separate bug fix and
needs its own patch.

--
balbi

Attachments:
(No filename) (2.88 kB)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-17 19:28:48

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > More power supply drivers depends on vbus events and
> > > > without it they not working. Power supply drivers using
> > > > usb_register_notifier, so to deliver events it is
> > > > needed to call atomic_notifier_call_chain.
> > > >
> > > > So without atomic notifier power supply driver isp1704
> > > > not retrieving vbus status and reporting bogus values
> > > > to userspace and also to board platform data functions.
> > > > Without proper data charger drivers trying to charge
> > > > battery also when charger is disconnected or do not
> > > > start charging when wallcharger connects.
> > > >
> > > > Atomic notifier in musb driver was used before v3.5 and
> > > > was replaced with omap mailbox. This patch adding
> > > > atomic_notifier_call_chain call from function
> > > > omap_musb_set_mailbox.
> > > >
> > > > Signed-off-by: Pali Rohár <[email protected]>
> > > > ---
> > > >
> > > > drivers/usb/musb/omap2430.c | 3 +++
> > > > drivers/usb/phy/phy-twl4030-usb.c | 2 ++
> > > > 2 files changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > +++ b/drivers/usb/musb/omap2430.c
> > > > @@ -305,6 +305,9 @@ static void
> > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > >
> > > > default:
> > > > dev_dbg(dev, "ID float\n");
> > > >
> > > > }
> > > >
> > > > +
> > > > + atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > + musb->xceiv->last_event, NULL);
> > >
> > > let's add a wrapper for this:
> > >
> > > static inline int usb_phy_notify(struct usb phy *x,
> > > unsigned val, void *v) {
> > >
> > > return atomic_notifier_call_chain(&x->notifier, val, v);
> > >
> > > }
> >
> > Where to add this wrapper? To omap2430.c? or some include
> > file?
>
> <linux/usb/phy.h>
>
> > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > 8f78d2d..efe6155 100644
> > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > platform_device *pdev)
> > > >
> > > > if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > > >
> > > > dev_warn(&pdev->dev, "could not create sysfs
> > > > file\n");
> > > >
> > > > + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > >
> > > BTW, this is a bugfix, send separately.
> >
> > What to send separately?
> >
> > This full patch 1/4 is bugfix. And I did not understand what
> > you want. Maybe it could be easier for you to apply this
> > small 3+2 lines patch how you need.
>
> This hunk here (initializaing notifier head) is a separate bug
> fix and needs its own patch.

So will you do that? Or it is needed to resend this one line hunk
again in new email again?

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-18 01:51:37

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Roh?r wrote:
> On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > More power supply drivers depends on vbus events and
> > > > > without it they not working. Power supply drivers using
> > > > > usb_register_notifier, so to deliver events it is
> > > > > needed to call atomic_notifier_call_chain.
> > > > >
> > > > > So without atomic notifier power supply driver isp1704
> > > > > not retrieving vbus status and reporting bogus values
> > > > > to userspace and also to board platform data functions.
> > > > > Without proper data charger drivers trying to charge
> > > > > battery also when charger is disconnected or do not
> > > > > start charging when wallcharger connects.
> > > > >
> > > > > Atomic notifier in musb driver was used before v3.5 and
> > > > > was replaced with omap mailbox. This patch adding
> > > > > atomic_notifier_call_chain call from function
> > > > > omap_musb_set_mailbox.
> > > > >
> > > > > Signed-off-by: Pali Roh?r <[email protected]>
> > > > > ---
> > > > >
> > > > > drivers/usb/musb/omap2430.c | 3 +++
> > > > > drivers/usb/phy/phy-twl4030-usb.c | 2 ++
> > > > > 2 files changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > @@ -305,6 +305,9 @@ static void
> > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > >
> > > > > default:
> > > > > dev_dbg(dev, "ID float\n");
> > > > >
> > > > > }
> > > > >
> > > > > +
> > > > > + atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > + musb->xceiv->last_event, NULL);
> > > >
> > > > let's add a wrapper for this:
> > > >
> > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > unsigned val, void *v) {
> > > >
> > > > return atomic_notifier_call_chain(&x->notifier, val, v);
> > > >
> > > > }
> > >
> > > Where to add this wrapper? To omap2430.c? or some include
> > > file?
> >
> > <linux/usb/phy.h>
> >
> > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > 8f78d2d..efe6155 100644
> > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > > platform_device *pdev)
> > > > >
> > > > > if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > > > >
> > > > > dev_warn(&pdev->dev, "could not create sysfs
> > > > > file\n");
> > > > >
> > > > > + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > >
> > > > BTW, this is a bugfix, send separately.
> > >
> > > What to send separately?
> > >
> > > This full patch 1/4 is bugfix. And I did not understand what
> > > you want. Maybe it could be easier for you to apply this
> > > small 3+2 lines patch how you need.
> >
> > This hunk here (initializaing notifier head) is a separate bug
> > fix and needs its own patch.
>
> So will you do that? Or it is needed to resend this one line hunk
> again in new email again?

new patch, new email

--
balbi

Attachments:
(No filename) (3.46 kB)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-18 08:20:26

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > > More power supply drivers depends on vbus events and
> > > > > > without it they not working. Power supply drivers
> > > > > > using usb_register_notifier, so to deliver events
> > > > > > it is needed to call atomic_notifier_call_chain.
> > > > > >
> > > > > > So without atomic notifier power supply driver
> > > > > > isp1704 not retrieving vbus status and reporting
> > > > > > bogus values to userspace and also to board
> > > > > > platform data functions. Without proper data
> > > > > > charger drivers trying to charge battery also when
> > > > > > charger is disconnected or do not start charging
> > > > > > when wallcharger connects.
> > > > > >
> > > > > > Atomic notifier in musb driver was used before v3.5
> > > > > > and was replaced with omap mailbox. This patch
> > > > > > adding atomic_notifier_call_chain call from
> > > > > > function omap_musb_set_mailbox.
> > > > > >
> > > > > > Signed-off-by: Pali Rohár <[email protected]>
> > > > > > ---
> > > > > >
> > > > > > drivers/usb/musb/omap2430.c | 3 +++
> > > > > > drivers/usb/phy/phy-twl4030-usb.c | 2 ++
> > > > > > 2 files changed, 5 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > > @@ -305,6 +305,9 @@ static void
> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > > >
> > > > > > default:
> > > > > > dev_dbg(dev, "ID float\n");
> > > > > >
> > > > > > }
> > > > > >
> > > > > > +
> > > > > > + atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > > + musb->xceiv->last_event, NULL);
> > > > >
> > > > > let's add a wrapper for this:
> > > > >
> > > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > > unsigned val, void *v) {
> > > > >
> > > > > return atomic_notifier_call_chain(&x->notifier, val,
> > > > > v);
> > > > >
> > > > > }
> > > >
> > > > Where to add this wrapper? To omap2430.c? or some
> > > > include file?
> > >
> > > <linux/usb/phy.h>
> > >
> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > > 8f78d2d..efe6155 100644
> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > @@ -705,6 +705,8 @@ static int
> > > > > > twl4030_usb_probe(struct platform_device *pdev)
> > > > > >
> > > > > > if (device_create_file(&pdev->dev,
> > > > > > &dev_attr_vbus))
> > > > > >
> > > > > > dev_warn(&pdev->dev, "could not create sysfs
> > > > > > file\n");
> > > > > >
> > > > > > + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > >
> > > > > BTW, this is a bugfix, send separately.
> > > >
> > > > What to send separately?
> > > >
> > > > This full patch 1/4 is bugfix. And I did not understand
> > > > what you want. Maybe it could be easier for you to
> > > > apply this small 3+2 lines patch how you need.
> > >
> > > This hunk here (initializaing notifier head) is a separate
> > > bug fix and needs its own patch.
> >
> > So will you do that? Or it is needed to resend this one line
> > hunk again in new email again?
>
> new patch, new email

Guys, WHY ARE YOU SO STUPID AND ARROGANT?

Sorry but, need to copy full isolated patch/hunk from one mail to
another is hassling. So what you want from me? Do all those non
sense working only because yesterday you had bad day? Or what?

Everything needed with described information was in first mail.
Also second hunk has full isolated "git diff" output, so it is for
you really big problem to copy it? Or you did not see that patch?

I really did not understand what you wanted from me.

============================
==== BEGINNING OF PATCH ====
============================

This is bugfix and sending this patch separately from all other patches.
This patch is visibly isolated from all others and could be readable also
by disabled people. For other handicapped people I suggest to increase
font size and other text settings in program which view this patch.
For visually impaired people I suggest to use some text-to-speech software.

This is small 2 lines patch, diff starting after next visible break.

This patch initializing notifier head in tw4030 usb code which is missing.
Initialization code is needed for using any atomic_notifier_* functions.

Signed-off-by: Pali Rohár <[email protected]>

===========================
==== BEGINNING OF DIFF ====
===========================

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
if (device_create_file(&pdev->dev, &dev_attr_vbus))
dev_warn(&pdev->dev, "could not create sysfs file\n");

+ ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
/* Our job is to use irqs and status from the power module
* to keep the transceiver disabled when nothing's connected.
*

======================
==== END OF PATCH ====
======================

PS: This is end of email and patch is above ^^^^

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-18 09:05:22

by Javier Martinez Canillas

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Wed, Sep 18, 2013 at 10:20 AM, Pali Rohár <[email protected]> wrote:
> On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
>> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
>> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
>> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
>> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
>> > > > > > More power supply drivers depends on vbus events and
>> > > > > > without it they not working. Power supply drivers
>> > > > > > using usb_register_notifier, so to deliver events
>> > > > > > it is needed to call atomic_notifier_call_chain.
>> > > > > >
>> > > > > > So without atomic notifier power supply driver
>> > > > > > isp1704 not retrieving vbus status and reporting
>> > > > > > bogus values to userspace and also to board
>> > > > > > platform data functions. Without proper data
>> > > > > > charger drivers trying to charge battery also when
>> > > > > > charger is disconnected or do not start charging
>> > > > > > when wallcharger connects.
>> > > > > >
>> > > > > > Atomic notifier in musb driver was used before v3.5
>> > > > > > and was replaced with omap mailbox. This patch
>> > > > > > adding atomic_notifier_call_chain call from
>> > > > > > function omap_musb_set_mailbox.
>> > > > > >
>> > > > > > Signed-off-by: Pali Rohár <[email protected]>
>> > > > > > ---
>> > > > > >
>> > > > > > drivers/usb/musb/omap2430.c | 3 +++
>> > > > > > drivers/usb/phy/phy-twl4030-usb.c | 2 ++
>> > > > > > 2 files changed, 5 insertions(+)
>> > > > > >
>> > > > > > diff --git a/drivers/usb/musb/omap2430.c
>> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
>> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
>> > > > > > +++ b/drivers/usb/musb/omap2430.c
>> > > > > > @@ -305,6 +305,9 @@ static void
>> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
>> > > > > >
>> > > > > > default:
>> > > > > > dev_dbg(dev, "ID float\n");
>> > > > > >
>> > > > > > }
>> > > > > >
>> > > > > > +
>> > > > > > + atomic_notifier_call_chain(&musb->xceiv->notifier,
>> > > > > > + musb->xceiv->last_event, NULL);
>> > > > >
>> > > > > let's add a wrapper for this:
>> > > > >
>> > > > > static inline int usb_phy_notify(struct usb phy *x,
>> > > > > unsigned val, void *v) {
>> > > > >
>> > > > > return atomic_notifier_call_chain(&x->notifier, val,
>> > > > > v);
>> > > > >
>> > > > > }
>> > > >
>> > > > Where to add this wrapper? To omap2430.c? or some
>> > > > include file?
>> > >
>> > > <linux/usb/phy.h>
>> > >
>> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
>> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
>> > > > > > 8f78d2d..efe6155 100644
>> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > @@ -705,6 +705,8 @@ static int
>> > > > > > twl4030_usb_probe(struct platform_device *pdev)
>> > > > > >
>> > > > > > if (device_create_file(&pdev->dev,
>> > > > > > &dev_attr_vbus))
>> > > > > >
>> > > > > > dev_warn(&pdev->dev, "could not create sysfs
>> > > > > > file\n");
>> > > > > >
>> > > > > > + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
>> > > > >
>> > > > > BTW, this is a bugfix, send separately.
>> > > >
>> > > > What to send separately?
>> > > >
>> > > > This full patch 1/4 is bugfix. And I did not understand
>> > > > what you want. Maybe it could be easier for you to
>> > > > apply this small 3+2 lines patch how you need.
>> > >
>> > > This hunk here (initializaing notifier head) is a separate
>> > > bug fix and needs its own patch.
>> >
>> > So will you do that? Or it is needed to resend this one line
>> > hunk again in new email again?
>>
>> new patch, new email
>
> Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>
> Sorry but, need to copy full isolated patch/hunk from one mail to
> another is hassling. So what you want from me? Do all those non
> sense working only because yesterday you had bad day? Or what?
>
> Everything needed with described information was in first mail.
> Also second hunk has full isolated "git diff" output, so it is for
> you really big problem to copy it? Or you did not see that patch?
>
> I really did not understand what you wanted from me.
>
> ============================
> ==== BEGINNING OF PATCH ====
> ============================
>
> This is bugfix and sending this patch separately from all other patches.
> This patch is visibly isolated from all others and could be readable also
> by disabled people. For other handicapped people I suggest to increase
> font size and other text settings in program which view this patch.
> For visually impaired people I suggest to use some text-to-speech software.
>
> This is small 2 lines patch, diff starting after next visible break.
>
> This patch initializing notifier head in tw4030 usb code which is missing.
> Initialization code is needed for using any atomic_notifier_* functions.
>
> Signed-off-by: Pali Rohár <[email protected]>
>
> ===========================
> ==== BEGINNING OF DIFF ====
> ===========================
>
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
> if (device_create_file(&pdev->dev, &dev_attr_vbus))
> dev_warn(&pdev->dev, "could not create sysfs file\n");
>
> + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
> /* Our job is to use irqs and status from the power module
> * to keep the transceiver disabled when nothing's connected.
> *
>
> ======================
> ==== END OF PATCH ====
> ======================
>
> PS: This is end of email and patch is above ^^^^
>

Hi Pali,

There is no need to be rude.

Felipe asked you to do the split since he believes that the notifier
chain call for musb xceiv and the twl->phy notifier head init should
be done in two separate patches.

I agree with him since is better to separate bugfixs from new features
for different reasons. For example if is found that a feature has to
be reverted, then this won't revert a bugfix causing a regression.
Also, it is easier to review and the bugfix patch can be cherry-picked
by stable kernels.

You said that to copy isolated patch/hunk from one mail to another is
hassling so why do you want Felipe to do that? He like most most
sub-system maintainers is very busy so if we want the kernel to scale
we have to help them to make their live easier.

So, I don't understand from where your anger comes for just the need
to split your patch in two and send correct patches with git
send-email so Felipe can apply easily with git am mbox or whatever
worfklow he has.

This is not the first time you contribute to the kernel so you know
that the above patch s not only not in the correct format to be
applied but also has a very offensive commit changelog that is not
suitable for the kernel.

Take a deep breath, grab a mug of coffee and then just split your
patches and repost as v2, I'm sure you spent more time writing that
angry email that what it would have taken to do it properly ;-)

> --
> Pali Rohár
> [email protected]

Best regards,
Javier

2013-09-18 13:30:28

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

Hi!

> >> > So will you do that? Or it is needed to resend this one line
> >> > hunk again in new email again?
> >>
> >> new patch, new email
> >
> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >
> > Sorry but, need to copy full isolated patch/hunk from one mail to
> > another is hassling. So what you want from me? Do all those non
> > sense working only because yesterday you had bad day? Or what?
...
>
> Hi Pali,
>
> There is no need to be rude.
>
> Felipe asked you to do the split since he believes that the notifier
> chain call for musb xceiv and the twl->phy notifier head init should
> be done in two separate patches.

Actually, there is need to be rude, because Felipe fails to act as
maintainer. Instead of fixing bugs in his code, he bounces bugfix
patches, points people to random READMEs and wastes everyones time.
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2013-09-18 13:57:35

by Javier Martinez Canillas

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Wed, Sep 18, 2013 at 3:30 PM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>> >> > So will you do that? Or it is needed to resend this one line
>> >> > hunk again in new email again?
>> >>
>> >> new patch, new email
>> >
>> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >
>> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> > another is hassling. So what you want from me? Do all those non
>> > sense working only because yesterday you had bad day? Or what?
> ...
>>
>> Hi Pali,
>>
>> There is no need to be rude.
>>
>> Felipe asked you to do the split since he believes that the notifier
>> chain call for musb xceiv and the twl->phy notifier head init should
>> be done in two separate patches.
>
> Actually, there is need to be rude, because Felipe fails to act as
> maintainer. Instead of fixing bugs in his code, he bounces bugfix
> patches, points people to random READMEs and wastes everyones time.
> Pavel
>

I don't know what are you talking about (if that happened in another
thread then I need more context). Felipe is not bouncing any bugfix
but just asked to split the patch in two since the patch was solving
two separate issues so is way better to have it in two separate
patches for the reasons I explained before.

So, as far as I can tell Felipe did exactly what I would expect from a
maintainer. He took the time to review the patches sent to him and
gave feedback. If the sender doesn't want to take his feedback into
account and prefer to send pretty insulting emails instead that is his
choice but I would say that is this not the greatest approach to get
your code merged (to say the least).

Best regards,
Javier

2013-09-18 14:22:08

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

Hi!

> >> >> > So will you do that? Or it is needed to resend this one line
> >> >> > hunk again in new email again?
> >> >>
> >> >> new patch, new email
> >> >
> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >> >
> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
> >> > another is hassling. So what you want from me? Do all those non
> >> > sense working only because yesterday you had bad day? Or what?
...
> > Actually, there is need to be rude, because Felipe fails to act as
> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
> > patches, points people to random READMEs and wastes everyones time.
>
> I don't know what are you talking about (if that happened in another
> thread then I need more context). Felipe is not bouncing any bugfix

Take a look here:

https://lkml.org/lkml/2013/9/17/286

I clearly state that patch can not be tested as required for "proper"
submission, but offer patch anyway. I get irrelevant boilerplate on
patch format.

> but just asked to split the patch in two since the patch was solving
> two separate issues so is way better to have it in two separate
> patches for the reasons I explained before.
>
> So, as far as I can tell Felipe did exactly what I would expect from a
> maintainer. He took the time to review the patches sent to him and

I'd expect maintainer to, well, maintain code. It means actually
fixing bugs in his code, when he's pointed at them.

> gave feedback. If the sender doesn't want to take his feedback into
> account and prefer to send pretty insulting emails instead that is his
> choice but I would say that is this not the greatest approach to get
> your code merged (to say the least).

Clearly not. But Pali found bug in code Felipe should
maintain. Instead of "thank you for bug report, I applied this one
line of your code to fix it", Pali got "new patch, new email" for his
efforts. That is how you train dogs, not how you should treat kernel
contributors.

Now, it is possible that Felipe just has problems with english, as he
called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
he appears more arogant than usual over email.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2013-09-18 14:35:40

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

Hi!

> > gave feedback. If the sender doesn't want to take his feedback into
> > account and prefer to send pretty insulting emails instead that is his
> > choice but I would say that is this not the greatest approach to get
> > your code merged (to say the least).
>
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
>
> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.

Actually he called me "piece of wood with garbage in it". I guess I
have right to be offended. I'm baby in the next email. Hmm.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2013-09-18 14:53:53

by Javier Martinez Canillas

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Wed, Sep 18, 2013 at 4:22 PM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>> >> >> > So will you do that? Or it is needed to resend this one line
>> >> >> > hunk again in new email again?
>> >> >>
>> >> >> new patch, new email
>> >> >
>> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >> >
>> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> >> > another is hassling. So what you want from me? Do all those non
>> >> > sense working only because yesterday you had bad day? Or what?
> ...
>> > Actually, there is need to be rude, because Felipe fails to act as
>> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
>> > patches, points people to random READMEs and wastes everyones time.
>>
>> I don't know what are you talking about (if that happened in another
>> thread then I need more context). Felipe is not bouncing any bugfix
>
> Take a look here:
>
> https://lkml.org/lkml/2013/9/17/286
>
> I clearly state that patch can not be tested as required for "proper"
> submission, but offer patch anyway. I get irrelevant boilerplate on
> patch format.
>

Felipe didn't complain about you not being to be able to test the
patch (most of the times compile tested if enough) what he said was:

"Seriously though, read that file, you're commit log has garbage in it
which shouldn't go to git history".

which is totally true, if you want to comment things that don't have
to go to the backlog you can't comment between the --- after your
s-o-b and before the first diff. That's were you should puts comments
like "Hi! or Here's suggested patch. I don't have the hardware, so it
is completely untested."

>> but just asked to split the patch in two since the patch was solving
>> two separate issues so is way better to have it in two separate
>> patches for the reasons I explained before.
>>
>> So, as far as I can tell Felipe did exactly what I would expect from a
>> maintainer. He took the time to review the patches sent to him and
>
> I'd expect maintainer to, well, maintain code. It means actually
> fixing bugs in his code, when he's pointed at them.
>
>> gave feedback. If the sender doesn't want to take his feedback into
>> account and prefer to send pretty insulting emails instead that is his
>> choice but I would say that is this not the greatest approach to get
>> your code merged (to say the least).
>
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
>

No, you misunderstood the role of the maintainers. Maintainers should
be custodian of a part of the kernel but not responsible for every
single line of code on their sub-systems. If a piece of code is buggy
then the people using and that take care of that should be fixing and
maintainers should review and suggest improvements to the patches. As
long as a piece of code keep compiling then it is harmless even if is
buggy and nobody cares about it. If it is so broken that it doesn't
even compile then the maintainer can decide to just drop it since no
one else seems to care about it.

If someone finds a bug on a piece of code is because that people care
about that functionality. Maintainers are really busy people and can
jump and fix any random bug that someone finds on a piece of code just
because it is the subsystem they maintainer neither they have to
blindly merge any crappy patch just because they don't have time (or
interest) in fixing a reported bug on a piece of code.

> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.
>

Clearly he meant "your commit log has garbage" instead of you're, that's a typo.

> Pavel

But neither Felipe needs someone to defend him nor I have time to keep
arguing with you.

Have nice day!
Javier

2013-09-18 15:56:18

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas
wrote:
> to split the patch in two since the patch was solving
> two separate issues

My patch does not solving *two* issues. It is *one* regression
and both parts of patch are needed for fixing it. Read commit
message again. It does not make sense to split patch fixing kernel
regression into more one line patches - or please clarify why.

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-18 16:27:52

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

Hi,

On Wed, Sep 18, 2013 at 04:35:37PM +0200, Pavel Machek wrote:
> Hi!
>
> > > gave feedback. If the sender doesn't want to take his feedback into
> > > account and prefer to send pretty insulting emails instead that is his
> > > choice but I would say that is this not the greatest approach to get
> > > your code merged (to say the least).
> >
> > Clearly not. But Pali found bug in code Felipe should
> > maintain. Instead of "thank you for bug report, I applied this one
> > line of your code to fix it", Pali got "new patch, new email" for his
> > efforts. That is how you train dogs, not how you should treat kernel
> > contributors.
> >
> > Now, it is possible that Felipe just has problems with english, as he
> > called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> > he appears more arogant than usual over email.
>
> Actually he called me "piece of wood with garbage in it". I guess I
> have right to be offended. I'm baby in the next email. Hmm.

what a baby. Grow up dude, just grow up. I said your commit log has
garbage which shouldn't be there (there was a typo you're instead of
your).

--
balbi

Attachments:
(No filename) (1.11 kB)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-18 16:38:41

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Roh?r wrote:
> On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas
> wrote:
> > to split the patch in two since the patch was solving
> > two separate issues
>
> My patch does not solving *two* issues. It is *one* regression
> and both parts of patch are needed for fixing it. Read commit
> message again. It does not make sense to split patch fixing kernel
> regression into more one line patches - or please clarify why.

issue 1) twl4030-usb.c doesn't initialize atomic notifier head
issue 2) musb doesn't call notifier chain

do you need a drawing ?

--
balbi

Attachments:
(No filename) (630.00 B)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-18 16:43:55

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > Canillas
> >
> > wrote:
> > > to split the patch in two since the patch was solving
> > > two separate issues
> >
> > My patch does not solving *two* issues. It is *one*
> > regression and both parts of patch are needed for fixing
> > it. Read commit message again. It does not make sense to
> > split patch fixing kernel regression into more one line
> > patches - or please clarify why.
>
> issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> issue 2) musb doesn't call notifier chain
>
> do you need a drawing ?

Regression 1) power supply drivers not working since v3.5

Look at firsts emails.


Do you really have problem to do what *you* need with 1 line
patch which I sent? Or what what you want?

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-18 16:50:13

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

On Wed, Sep 18, 2013 at 06:43:49PM +0200, Pali Roh?r wrote:
> On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> > On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Roh?r wrote:
> > > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > > Canillas
> > >
> > > wrote:
> > > > to split the patch in two since the patch was solving
> > > > two separate issues
> > >
> > > My patch does not solving *two* issues. It is *one*
> > > regression and both parts of patch are needed for fixing
> > > it. Read commit message again. It does not make sense to
> > > split patch fixing kernel regression into more one line
> > > patches - or please clarify why.
> >
> > issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> > issue 2) musb doesn't call notifier chain
> >
> > do you need a drawing ?
>
> Regression 1) power supply drivers not working since v3.5
>
> Look at firsts emails.
>
>
> Do you really have problem to do what *you* need with 1 line
> patch which I sent? Or what what you want?

if you had already resent patches the way I requested, they'd already be
applied. Instead you chose to troll the people who are trying to helping
out.

You have two issues being fixed in the same patch and that's not
acceptable.

--
balbi

Attachments:
(No filename) (1.23 kB)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-18 17:03:42

by Pali Rohár

[permalink] [raw]
Subject: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

&twl->phy.notifier is not initalized

Signed-off-by: Pali Rohár <[email protected]>

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
if (device_create_file(&pdev->dev, &dev_attr_vbus))
dev_warn(&pdev->dev, "could not create sysfs file\n");

+ ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
/* Our job is to use irqs and status from the power module
* to keep the transceiver disabled when nothing's connected.
*

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-18 17:03:41

by Pali Rohár

[permalink] [raw]
Subject: [PATCH usb 2/2] usb: musb: Call atomic_notifier_call_chain when status is changed

More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.

So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting bogus values to userspace and also to board
platform data functions. Without proper data charger drivers trying to
charge battery also when charger is disconnected or do not start charging
when wallcharger connects.

Atomic notifier in musb driver was used before v3.5 and was replaced with
omap mailbox. This patch adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.

Signed-off-by: Pali Rohár <[email protected]>

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..5c40252 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
default:
dev_dbg(dev, "ID float\n");
}
+
+ atomic_notifier_call_chain(&musb->xceiv->notifier,
+ musb->xceiv->last_event, NULL);
}

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-20 19:22:15

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

On Sunday 08 September 2013 10:50:39 Pali Rohár wrote:
> This patch will register bq24150a charger in RX-51 board data.
> Patch also adding platform function between isp1704 and
> bq2415x drivers for detecting charger type.
>
> So finally charging battery on Nokia N900 (RX-51) working
> automatically without any proprietary Nokia bits in userspace.
>
> Signed-off-by: Pali Rohár <[email protected]>
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 56
> +++++++++++++++++++++++++- 1 file changed, 55 insertions(+),
> 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c index
> 9c2dd10..a993ffe 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -25,6 +25,7 @@
> #include <linux/gpio_keys.h>
> #include <linux/mmc/host.h>
> #include <linux/power/isp1704_charger.h>
> +#include <linux/power/bq2415x_charger.h>
> #include <linux/platform_data/spi-omap2-mcspi.h>
> #include <linux/platform_data/mtd-onenand-omap2.h>
>
> @@ -270,6 +271,44 @@ static struct platform_device
> rx51_battery_device = { .id = -1,
> };
>
> +static enum bq2415x_mode rx51_charger_mode =
> BQ2415X_MODE_OFF; +static void *rx51_charger_hook_data;
> +static void (*rx51_charger_hook)(enum bq2415x_mode mode, void
> *data); +
> +static int rx51_charger_set_hook(
> + void (*hook)(enum bq2415x_mode mode, void *data), void
> *data) +{
> + rx51_charger_hook = hook;
> + rx51_charger_hook_data = data;
> + if (rx51_charger_hook)
> + rx51_charger_hook(rx51_charger_mode,
> rx51_charger_hook_data); + return 1;
> +}
> +
> +static void rx51_charger_set_current(int mA)
> +{
> + enum bq2415x_mode mode;
> +
> + pr_info("RX-51: Charger current limit is %d mA\n", mA);
> +
> + if (mA == 0)
> + mode = BQ2415X_MODE_OFF;
> + else if (mA < 500)
> + mode = BQ2415X_MODE_NONE;
> + else if (mA < 1800)
> + mode = BQ2415X_MODE_HOST_CHARGER;
> + else
> + mode = BQ2415X_MODE_DEDICATED_CHARGER;
> +
> + if (rx51_charger_mode == mode)
> + return;
> +
> + rx51_charger_mode = mode;
> +
> + if (rx51_charger_hook)
> + rx51_charger_hook(rx51_charger_mode,
> rx51_charger_hook_data); +}
> +
> static void rx51_charger_set_power(bool on)
> {
> gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
> @@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool
> on)
>
> static struct isp1704_charger_data rx51_charger_data = {
> .set_power = rx51_charger_set_power,
> + .set_current = rx51_charger_set_current,
> };
>
> static struct platform_device rx51_charger_device = {
> @@ -1017,6 +1057,16 @@ static struct aic3x_pdata
> rx51_aic3x_data2 = { .gpio_reset = 60,
> };
>
> +static struct bq2415x_platform_data
> rx51_bq24150a_platform_data = { + .current_limit = 100,
/*
> mA */
> + .weak_battery_voltage = 3400, /* mV */
> + .battery_regulation_voltage = 4200, /* mV */
> + .charge_current = 650, /* mA */
> + .termination_current = 100, /* mA */
> + .resistor_sense = 68, /* m ohm */
> + .set_mode_hook = &rx51_charger_set_hook,
> +};
> +
> static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_2[] = { {
> I2C_BOARD_INFO("tlv320aic3x", 0x18),
> @@ -1044,7 +1094,11 @@ static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_2[] = { {
> I2C_BOARD_INFO("tpa6130a2", 0x60),
> .platform_data = &rx51_tpa6130a2_data,
> - }
> + },
> + {
> + I2C_BOARD_INFO("bq24150a", 0x6b),
> + .platform_data = &rx51_bq24150a_platform_data,
> + },
> };
>
> static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_3[] = {

Tony, can you look and review this board patch?

I think that this patch series it the most important for Nokia
N900, because it finally bringing charging support. And without
charging battery it very hard to use phone which has power supply
only from battery.

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-21 13:42:44

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 0/4] Add support for charging battery in Nokia RX-51

On Sunday 08 September 2013 10:50:35 Pali Rohár wrote:
> This patch series finally bringing support for charging
> battery on Nokia N900 (RX-51) without any proprietary Nokia
> bits in userspace.
>
> Pali Rohár (4):
> usb: musb: Call atomic_notifier_call_chain when status is
> changed power: isp1704_charger: Fix driver to work with
> changes introduced in v3.5
> power: isp1704_charger: Add callback function set_current
> RX-51: Add platform function and data for bq24150a charger
>
> arch/arm/mach-omap2/board-rx51-peripherals.c | 56
> +++++++++++++- drivers/power/isp1704_charger.c |
> 107 ++++++++++++++------------ drivers/usb/musb/omap2430.c
> | 3 + drivers/usb/phy/phy-twl4030-usb.c
> | 2 + include/linux/power/isp1704_charger.h
> | 1 + 5 files changed, 117 insertions(+), 52 deletions(-)

Anton, can you review this patch series, specially power supply
code (changes to isp1704_charger.c driver)?

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-23 18:03:17

by Tony Lindgren

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

* Pali Rohár <[email protected]> [130920 12:29]:
> On Sunday 08 September 2013 10:50:39 Pali Rohár wrote:
> > This patch will register bq24150a charger in RX-51 board data.
> > Patch also adding platform function between isp1704 and
> > bq2415x drivers for detecting charger type.
> >
> > So finally charging battery on Nokia N900 (RX-51) working
> > automatically without any proprietary Nokia bits in userspace.
...

> > @@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool
> > on)
> >
> > static struct isp1704_charger_data rx51_charger_data = {
> > .set_power = rx51_charger_set_power,
> > + .set_current = rx51_charger_set_current,
> > };

We want to get rid of the platform data callbacks here,
there no longer any need to keep these under arch/arm.

> Tony, can you look and review this board patch?

Yes, looks like this can all be done in the driver nowadays.
You can use drivers/reset for the set_power. Or if it's really
controlling the regulator, then the regulator framework. The
info can be passed in a .dts file for those.

The .set_current you can do in the driver based on the
compatible flag.

> I think that this patch series it the most important for Nokia
> N900, because it finally bringing charging support. And without
> charging battery it very hard to use phone which has power supply
> only from battery.

Right, let's get this driver updated to use the device tree
based init and that way this file is no longer needed.
I would like to $ grep -i grandmom ~/.phonebook | call too :)

I forgot how this charger is wired up, but maybe take a
look at commit d7bf353f (bq24190_charger: Add support for TI
BQ24190 Battery Charger) for the DT parts.

Regards,

Tony

2013-09-23 19:16:24

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

Hello,

On Monday 23 September 2013 20:03:00 you wrote:
> * Pali Rohár <[email protected]> [130920 12:29]:
> > On Sunday 08 September 2013 10:50:39 Pali Rohár wrote:
> > > This patch will register bq24150a charger in RX-51 board
> > > data. Patch also adding platform function between isp1704
> > > and bq2415x drivers for detecting charger type.
> > >
> > > So finally charging battery on Nokia N900 (RX-51) working
> > > automatically without any proprietary Nokia bits in
> > > userspace.
>
> ...
>
> > > @@ -277,6 +316,7 @@ static void
> > > rx51_charger_set_power(bool on)
> > >
> > > static struct isp1704_charger_data rx51_charger_data = {
> > >
> > > .set_power = rx51_charger_set_power,
> > >
> > > + .set_current = rx51_charger_set_current,
> > >
> > > };
>
> We want to get rid of the platform data callbacks here,
> there no longer any need to keep these under arch/arm.
>

Where to put rx51 board specified functions?
It cannot go to DT, because DT does not support C/ASM code.

> > Tony, can you look and review this board patch?
>
> Yes, looks like this can all be done in the driver nowadays.
> You can use drivers/reset for the set_power. Or if it's really
> controlling the regulator, then the regulator framework. The
> info can be passed in a .dts file for those.
>
> The .set_current you can do in the driver based on the
> compatible flag.
>

It is not as simple as it looks. This is reason why I submited
this patch long time after I submited bq2415x driver.

Problem is that for rx51 is needed specific function which connect
to two drivers (bq2415x and isp1704) plus it call specific rx51
board functions.

Something which cannot be in DT (unless DT support C/ASM code).

> > I think that this patch series it the most important for
> > Nokia N900, because it finally bringing charging support.
> > And without charging battery it very hard to use phone
> > which has power supply only from battery.
>
> Right, let's get this driver updated to use the device tree
> based init and that way this file is no longer needed.
> I would like to $ grep -i grandmom ~/.phonebook | call too :)
>

Patches for modem support are being prepared for upstreaming :-)
so after that it is up to you to create "call" script as you want

> I forgot how this charger is wired up, but maybe take a
> look at commit d7bf353f (bq24190_charger: Add support for TI
> BQ24190 Battery Charger) for the DT parts.
>
> Regards,
>
> Tony

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-23 20:00:22

by Sebastian Reichel

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> It is not as simple as it looks. This is reason why I submited
> this patch long time after I submited bq2415x driver.
>
> Problem is that for rx51 is needed specific function which connect
> to two drivers (bq2415x and isp1704) plus it call specific rx51
> board functions.
>
> Something which cannot be in DT (unless DT support C/ASM code).

mh could isp1704 driver expose the data via the regulator framework?
Then the bq2415x chip can just use the regulator framework. This
should make converting to DT easy (by giving the bq2415x chip the
isp1704 as regulator) and uses existing standard interfaces.

> Patches for modem support are being prepared for upstreaming :-)
> so after that it is up to you to create "call" script as you want

I'm on it. RFC round will be sent out this week. It seems
hwmod data is already finished, since i didn't get feedback for
that patch :)

-- Sebastian

Attachments:
(No filename) (960.00 B)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-23 20:06:52

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > It is not as simple as it looks. This is reason why I
> > submited this patch long time after I submited bq2415x
> > driver.
> >
> > Problem is that for rx51 is needed specific function which
> > connect to two drivers (bq2415x and isp1704) plus it call
> > specific rx51 board functions.
> >
> > Something which cannot be in DT (unless DT support C/ASM
> > code).
>
> mh could isp1704 driver expose the data via the regulator
> framework?

No, isp1704 is power supply driver and export data via power
supply (sysfs) interface. It is not regulator but charger driver.

> Then the bq2415x chip can just use the regulator
> framework. This should make converting to DT easy (by giving
> the bq2415x chip the isp1704 as regulator) and uses existing
> standard interfaces.
>
> > Patches for modem support are being prepared for upstreaming
> > :-) so after that it is up to you to create "call" script
> > as you want
>
> I'm on it. RFC round will be sent out this week. It seems
> hwmod data is already finished, since i didn't get feedback
> for that patch :)
>
> -- Sebastian

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-23 20:47:21

by Sebastian Reichel

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Roh?r wrote:
> On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> > > It is not as simple as it looks. This is reason why I
> > > submited this patch long time after I submited bq2415x
> > > driver.
> > >
> > > Problem is that for rx51 is needed specific function which
> > > connect to two drivers (bq2415x and isp1704) plus it call
> > > specific rx51 board functions.
> > >
> > > Something which cannot be in DT (unless DT support C/ASM
> > > code).
> >
> > mh could isp1704 driver expose the data via the regulator
> > framework?
>
> No, isp1704 is power supply driver and export data via power
> supply (sysfs) interface. It is not regulator but charger driver.

well it does not charge the battery directly, but just provides a
power line with 5 Volt and a specified amount of current to the
system, doesn't it?

From my POV this is a candiate for the regulator framework:

https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

-- Sebastian

Attachments:
(No filename) (1.07 kB)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-23 23:11:26

by Tony Lindgren

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

* Sebastian Reichel <[email protected]> [130923 13:55]:
> On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote:
> > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > > > It is not as simple as it looks. This is reason why I
> > > > submited this patch long time after I submited bq2415x
> > > > driver.
> > > >
> > > > Problem is that for rx51 is needed specific function which
> > > > connect to two drivers (bq2415x and isp1704) plus it call
> > > > specific rx51 board functions.
> > > >
> > > > Something which cannot be in DT (unless DT support C/ASM
> > > > code).
> > >
> > > mh could isp1704 driver expose the data via the regulator
> > > framework?
> >
> > No, isp1704 is power supply driver and export data via power
> > supply (sysfs) interface. It is not regulator but charger driver.
>
> well it does not charge the battery directly, but just provides a
> power line with 5 Volt and a specified amount of current to the
> system, doesn't it?
>
> From my POV this is a candiate for the regulator framework:
>
> https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

Yes I think we should be able handle that rail with the
regulator framework.

Regards,

Tony

2013-09-24 00:05:53

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

Hi!

> > No, isp1704 is power supply driver and export data via power
> > supply (sysfs) interface. It is not regulator but charger driver.
>
> well it does not charge the battery directly, but just provides a
> power line with 5 Volt and a specified amount of current to the
> system, doesn't it?

I don't want to talk about isp1704, but...

LiION charger is just something that provides 4.2V power line with
C/10 current limitation...

(IOW line between regulators and chargers is very very thin, if it
even exists).

Pavel

(who did use laboratory power supply as emergency battery charger)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2013-09-24 17:05:53

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

On Monday 23 September 2013 22:47:15 Sebastian Reichel wrote:
> On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote:
> > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > > > It is not as simple as it looks. This is reason why I
> > > > submited this patch long time after I submited bq2415x
> > > > driver.
> > > >
> > > > Problem is that for rx51 is needed specific function
> > > > which connect to two drivers (bq2415x and isp1704) plus
> > > > it call specific rx51 board functions.
> > > >
> > > > Something which cannot be in DT (unless DT support C/ASM
> > > > code).
> > >
> > > mh could isp1704 driver expose the data via the regulator
> > > framework?
> >
> > No, isp1704 is power supply driver and export data via power
> > supply (sysfs) interface. It is not regulator but charger
> > driver.
>
> well it does not charge the battery directly, but just
> provides a power line with 5 Volt and a specified amount of
> current to the system, doesn't it?
>

No, isp1704 driver is doing fastcharger detection (and then
export charger type via sysfs power supply) based on musb usb
events.

Real charging (enabling/disabling and setting properties) is done
by bq24150a chip which has own power driver bq2415x_charger.

As already wrote this is not simple and this is reason why I sent
board data and functions only now...

> From my POV this is a candiate for the regulator framework:
>
> https://www.kernel.org/doc/Documentation/power/regulator/overv
> iew.txt
>
> -- Sebastian

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-24 20:50:45

by Sebastian Reichel

[permalink] [raw]
Subject: Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

Hi,

On Tue, Sep 24, 2013 at 07:05:47PM +0200, Pali Roh?r wrote:
> No, isp1704 driver is doing fastcharger detection (and then
> export charger type via sysfs power supply) based on musb usb
> events.
>
> Real charging (enabling/disabling and setting properties) is done
> by bq24150a chip which has own power driver bq2415x_charger.
>
> As already wrote this is not simple and this is reason why I sent
> board data and functions only now...

Yes, I'm aware of this. Technically the isp1704 does not provide the
5 volt line, but for the system as a whole that fact does not really
matter.

The isp1704 can provide its functionality via the regulator API
as a simple regulator device. It provides information about the
power "it can supply".

The bq24150a on the other hand can just use the regulator via the
consumer interface.

The regulator framework provides capabilities for events:
"Regulators can notify consumers of external events"

-- Sebastian

Attachments:
(No filename) (961.00 B)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-25 08:17:48

by Pali Rohár

[permalink] [raw]
Subject: Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote:
> &twl->phy.notifier is not initalized
>
> Signed-off-by: Pali Rohár <[email protected]>
>
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> platform_device *pdev) if (device_create_file(&pdev->dev,
> &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> file\n");
>
> + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
> /* Our job is to use irqs and status from the power module
> * to keep the transceiver disabled when nothing's
> connected. *

I sent above patch week ago. Did you already included it?

--
Pali Rohár
[email protected]

Attachments:
signature.asc (198.00 B)
This is a digitally signed message part.

2013-09-25 20:34:32

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

Hi,

On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Roh?r wrote:
> On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> > &twl->phy.notifier is not initalized
> >
> > Signed-off-by: Pali Roh?r <[email protected]>
> >
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev) if (device_create_file(&pdev->dev,
> > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > file\n");
> >
> > + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > +
> > /* Our job is to use irqs and status from the power module
> > * to keep the transceiver disabled when nothing's
> > connected. *
>
> I sent above patch week ago. Did you already included it?

look at my testing branch.

--
balbi

Attachments:
(No filename) (949.00 B)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-09-26 00:01:03

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

On Wed 2013-09-25 15:33:33, Felipe Balbi wrote:
> Hi,
>
> On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Roh?r wrote:
> > On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> > > &twl->phy.notifier is not initalized
> > >
> > > Signed-off-by: Pali Roh?r <[email protected]>
> > >
> > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > 100644
> > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > platform_device *pdev) if (device_create_file(&pdev->dev,
> > > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > > file\n");
> > >
> > > + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > +
> > > /* Our job is to use irqs and status from the power module
> > > * to keep the transceiver disabled when nothing's
> > > connected. *
> >
> > I sent above patch week ago. Did you already included it?
>
> look at my testing branch.

Felipe prefers you to go MAINTAINERS file for

git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git

entry. After few clicks, you'll find out your two patches in

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing

. So yes, it seems that after 10+ flames Felipe was _not_ lazy to
send, "Thanks for a patch" mail was too much work.

Apparently, we'll need Documentation/HowToBeGoodMaintainer file...

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2013-10-01 14:23:58

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

Hi,

On Thu, Sep 26, 2013 at 02:00:59AM +0200, Pavel Machek wrote:
> > On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Roh?r wrote:
> > > On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> > > > &twl->phy.notifier is not initalized
> > > >
> > > > Signed-off-by: Pali Roh?r <[email protected]>
> > > >
> > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > > 100644
> > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > platform_device *pdev) if (device_create_file(&pdev->dev,
> > > > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > > > file\n");
> > > >
> > > > + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > +
> > > > /* Our job is to use irqs and status from the power module
> > > > * to keep the transceiver disabled when nothing's
> > > > connected. *
> > >
> > > I sent above patch week ago. Did you already included it?
> >
> > look at my testing branch.
>
> Felipe prefers you to go MAINTAINERS file for
>
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>
> entry. After few clicks, you'll find out your two patches in
>
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing
>
> . So yes, it seems that after 10+ flames Felipe was _not_ lazy to
> send, "Thanks for a patch" mail was too much work.
>
> Apparently, we'll need Documentation/HowToBeGoodMaintainer file...

I only send my automated emails after properly testing them. They sit in
'testing' for as long as necessary. After all the test is done, they'll
be moved to 'next' at which point you get your email notification and
they reach linux-next for the next day.

--
balbi

Attachments:
(No filename) (1.78 kB)
 signature.asc (836.00 B)
Digital signature Download all attachments

2013-10-22 21:03:44

by Anton Vorontsov

[permalink] [raw]
Subject: Re: [PATCH 2/4] power: isp1704_charger: Fix driver to work with changes introduced in v3.5

On Sun, Sep 08, 2013 at 10:50:37AM +0200, Pali Rohár wrote:
> * omap musb driver does not report USB_EVENT_ENUMERATED event anymore
> * omap musb driver reporting USB_EVENT_VBUS when charger is connected
> * read last event from phy->last_event (instead from ulpi register)
> * do not call wall charger detection more times
>
> Signed-off-by: Pali Rohár <[email protected]>

Applied, thanks a lot!

(Per others' review comments I am assuming that the second isp1704 patch
will be reworked to support device-tree, so I am not applying it.)

Thanks,

Anton