Re: I2C controller i2c-mv64xxx.c not compliant
Hi Rodolfo, Rodolfo Giometti said the following: I'm using a ltc4266 (PoE chip) with the Marvell i2c controller (CPU Feroceon 88FR131). you already solved your issue, but where did you get register and functional description of LTC from? Is it under NDA? I couldn't find it in the web, just a file named 4266fa.pdf not specifying registers. Are you willing to share your driver? -- KR Michael -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PM: Allow pm_runtime_suspend() to succeed during system suspend
On Monday, January 31, 2011, Rafael J. Wysocki wrote:
On Monday, January 31, 2011, Alan Stern wrote:
On Mon, 31 Jan 2011, Kevin Hilman wrote:
I understand how this works, but frankly I'm still a bit fuzzy on why.
I guess I'm still missing a good understanding of what interfering with a
system power transition means, and why a runtime suspend qualifies as
interfering but not a runtime resume.
These are good questions. Rafael implemented this design originally;
my contribution was only to warn him of the potential for problems.
Therefore he should explain the rationale for the design.
The reason why runtime resume is allowed during system power transitions is
because in some cases during system suspend we simply have to resume devices
that were previously runtime-suspended (for example, the PCI bus type does
that).
The reason why runtime suspend is not allowed during system power transitions
if the following race:
- A device has been suspended via a system suspend callback.
- The runtime PM framework executes a (scheduled) suspend on that device,
not knowing that it's already been suspended, which potentially results in
accessing the device's registers in a low-power state.
Now, it can be avoided if every driver does the right thing and checks whether
the device is already suspended in its runtime suspend callback, but that
would
kind of defeat the purpose of the runtime PM framework, at least partially.
In fact, I've just realized that the above race cannot really occur, because
pm_wq is freezable, so I'm proposing the following change.
Of course, it still doesn't prevent user space from disabling the runtime PM
framework's helpers via /sys/devices/.../power/control.
Thanks,
Rafael
---
From: Rafael J. Wysocki r...@sisk.pl
Subject: PM: Allow pm_runtime_suspend() to succeed during system suspend
The dpm_prepare() function increments the runtime PM reference
counters of all devices to prevent pm_runtime_suspend() from
executing subsystem-level callbacks. However, this was supposed to
guard against a specific race condition that cannot happen, because
the power management workqueue is freezable, so pm_runtime_suspend()
can only be called synchronously during system suspend and we can
rely on subsystems and device drivers to avoid doing that
unnecessarily.
Make dpm_prepare() drop the runtime PM reference to each device
after making sure that runtime resume is not pending for it.
Signed-off-by: Rafael J. Wysocki r...@sisk.pl
---
drivers/base/power/main.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
Index: linux-2.6/drivers/base/power/main.c
===
--- linux-2.6.orig/drivers/base/power/main.c
+++ linux-2.6/drivers/base/power/main.c
@@ -669,7 +669,6 @@ static void dpm_complete(pm_message_t st
mutex_unlock(dpm_list_mtx);
device_complete(dev, state);
- pm_runtime_put_sync(dev);
mutex_lock(dpm_list_mtx);
put_device(dev);
@@ -1005,12 +1004,9 @@ static int dpm_prepare(pm_message_t stat
if (pm_runtime_barrier(dev) device_may_wakeup(dev))
pm_wakeup_event(dev, 0);
- if (pm_wakeup_pending()) {
- pm_runtime_put_sync(dev);
- error = -EBUSY;
- } else {
- error = device_prepare(dev, state);
- }
+ pm_runtime_put_sync(dev);
+ error = pm_wakeup_pending() ?
+ -EBUSY : device_prepare(dev, state);
mutex_lock(dpm_list_mtx);
if (error) {
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Allow pm_runtime_suspend() to succeed during system suspend
On Fri, 11 Feb 2011, Rafael J. Wysocki wrote: The reason why runtime suspend is not allowed during system power transitions if the following race: - A device has been suspended via a system suspend callback. - The runtime PM framework executes a (scheduled) suspend on that device, not knowing that it's already been suspended, which potentially results in accessing the device's registers in a low-power state. Now, it can be avoided if every driver does the right thing and checks whether the device is already suspended in its runtime suspend callback, but that would kind of defeat the purpose of the runtime PM framework, at least partially. In fact, I've just realized that the above race cannot really occur, because pm_wq is freezable, so I'm proposing the following change. Yes, I had reached essentially the same conclusion. Of course, there may still be other kernel threads running or interrupt handlers that can interfere. It's probably okay to assume that drivers will handle these things. Of course, it still doesn't prevent user space from disabling the runtime PM framework's helpers via /sys/devices/.../power/control. True. So in the end this won't make much difference, but we might as well do it. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Allow pm_runtime_suspend() to succeed during system suspend
Rafael J. Wysocki r...@sisk.pl writes:
On Monday, January 31, 2011, Rafael J. Wysocki wrote:
On Monday, January 31, 2011, Alan Stern wrote:
On Mon, 31 Jan 2011, Kevin Hilman wrote:
I understand how this works, but frankly I'm still a bit fuzzy on why.
I guess I'm still missing a good understanding of what interfering with
a
system power transition means, and why a runtime suspend qualifies as
interfering but not a runtime resume.
These are good questions. Rafael implemented this design originally;
my contribution was only to warn him of the potential for problems.
Therefore he should explain the rationale for the design.
The reason why runtime resume is allowed during system power transitions is
because in some cases during system suspend we simply have to resume devices
that were previously runtime-suspended (for example, the PCI bus type does
that).
The reason why runtime suspend is not allowed during system power transitions
if the following race:
- A device has been suspended via a system suspend callback.
- The runtime PM framework executes a (scheduled) suspend on that device,
not knowing that it's already been suspended, which potentially results in
accessing the device's registers in a low-power state.
Now, it can be avoided if every driver does the right thing and checks
whether
the device is already suspended in its runtime suspend callback, but that
would
kind of defeat the purpose of the runtime PM framework, at least partially.
In fact, I've just realized that the above race cannot really occur, because
pm_wq is freezable, so I'm proposing the following change.
Of course, it still doesn't prevent user space from disabling the runtime PM
framework's helpers via /sys/devices/.../power/control.
Thanks,
Rafael
---
From: Rafael J. Wysocki r...@sisk.pl
Subject: PM: Allow pm_runtime_suspend() to succeed during system suspend
The dpm_prepare() function increments the runtime PM reference
counters of all devices to prevent pm_runtime_suspend() from
executing subsystem-level callbacks. However, this was supposed to
guard against a specific race condition that cannot happen, because
the power management workqueue is freezable, so pm_runtime_suspend()
can only be called synchronously during system suspend and we can
rely on subsystems and device drivers to avoid doing that
unnecessarily.
Make dpm_prepare() drop the runtime PM reference to each device
after making sure that runtime resume is not pending for it.
Signed-off-by: Rafael J. Wysocki r...@sisk.pl
---
Yes!
Acked-by: Kevin Hilman khil...@ti.com
drivers/base/power/main.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
Index: linux-2.6/drivers/base/power/main.c
===
--- linux-2.6.orig/drivers/base/power/main.c
+++ linux-2.6/drivers/base/power/main.c
@@ -669,7 +669,6 @@ static void dpm_complete(pm_message_t st
mutex_unlock(dpm_list_mtx);
device_complete(dev, state);
- pm_runtime_put_sync(dev);
mutex_lock(dpm_list_mtx);
put_device(dev);
@@ -1005,12 +1004,9 @@ static int dpm_prepare(pm_message_t stat
if (pm_runtime_barrier(dev) device_may_wakeup(dev))
pm_wakeup_event(dev, 0);
- if (pm_wakeup_pending()) {
- pm_runtime_put_sync(dev);
- error = -EBUSY;
- } else {
- error = device_prepare(dev, state);
- }
+ pm_runtime_put_sync(dev);
+ error = pm_wakeup_pending() ?
+ -EBUSY : device_prepare(dev, state);
mutex_lock(dpm_list_mtx);
if (error) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Allow pm_runtime_suspend() to succeed during system suspend
On Friday, February 11, 2011, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Monday, January 31, 2011, Rafael J. Wysocki wrote: On Monday, January 31, 2011, Alan Stern wrote: On Mon, 31 Jan 2011, Kevin Hilman wrote: I understand how this works, but frankly I'm still a bit fuzzy on why. I guess I'm still missing a good understanding of what interfering with a system power transition means, and why a runtime suspend qualifies as interfering but not a runtime resume. These are good questions. Rafael implemented this design originally; my contribution was only to warn him of the potential for problems. Therefore he should explain the rationale for the design. The reason why runtime resume is allowed during system power transitions is because in some cases during system suspend we simply have to resume devices that were previously runtime-suspended (for example, the PCI bus type does that). The reason why runtime suspend is not allowed during system power transitions if the following race: - A device has been suspended via a system suspend callback. - The runtime PM framework executes a (scheduled) suspend on that device, not knowing that it's already been suspended, which potentially results in accessing the device's registers in a low-power state. Now, it can be avoided if every driver does the right thing and checks whether the device is already suspended in its runtime suspend callback, but that would kind of defeat the purpose of the runtime PM framework, at least partially. In fact, I've just realized that the above race cannot really occur, because pm_wq is freezable, so I'm proposing the following change. Of course, it still doesn't prevent user space from disabling the runtime PM framework's helpers via /sys/devices/.../power/control. Thanks, Rafael --- From: Rafael J. Wysocki r...@sisk.pl Subject: PM: Allow pm_runtime_suspend() to succeed during system suspend The dpm_prepare() function increments the runtime PM reference counters of all devices to prevent pm_runtime_suspend() from executing subsystem-level callbacks. However, this was supposed to guard against a specific race condition that cannot happen, because the power management workqueue is freezable, so pm_runtime_suspend() can only be called synchronously during system suspend and we can rely on subsystems and device drivers to avoid doing that unnecessarily. Make dpm_prepare() drop the runtime PM reference to each device after making sure that runtime resume is not pending for it. Signed-off-by: Rafael J. Wysocki r...@sisk.pl --- Yes! Acked-by: Kevin Hilman khil...@ti.com Well, I hope you realize that it doesn't help you a lot? Rafael -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Allow pm_runtime_suspend() to succeed during system suspend
On Saturday, February 12, 2011, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Friday, February 11, 2011, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Monday, January 31, 2011, Rafael J. Wysocki wrote: On Monday, January 31, 2011, Alan Stern wrote: On Mon, 31 Jan 2011, Kevin Hilman wrote: I understand how this works, but frankly I'm still a bit fuzzy on why. I guess I'm still missing a good understanding of what interfering with a system power transition means, and why a runtime suspend qualifies as interfering but not a runtime resume. These are good questions. Rafael implemented this design originally; my contribution was only to warn him of the potential for problems. Therefore he should explain the rationale for the design. The reason why runtime resume is allowed during system power transitions is because in some cases during system suspend we simply have to resume devices that were previously runtime-suspended (for example, the PCI bus type does that). The reason why runtime suspend is not allowed during system power transitions if the following race: - A device has been suspended via a system suspend callback. - The runtime PM framework executes a (scheduled) suspend on that device, not knowing that it's already been suspended, which potentially results in accessing the device's registers in a low-power state. Now, it can be avoided if every driver does the right thing and checks whether the device is already suspended in its runtime suspend callback, but that would kind of defeat the purpose of the runtime PM framework, at least partially. In fact, I've just realized that the above race cannot really occur, because pm_wq is freezable, so I'm proposing the following change. Of course, it still doesn't prevent user space from disabling the runtime PM framework's helpers via /sys/devices/.../power/control. Thanks, Rafael --- From: Rafael J. Wysocki r...@sisk.pl Subject: PM: Allow pm_runtime_suspend() to succeed during system suspend The dpm_prepare() function increments the runtime PM reference counters of all devices to prevent pm_runtime_suspend() from executing subsystem-level callbacks. However, this was supposed to guard against a specific race condition that cannot happen, because the power management workqueue is freezable, so pm_runtime_suspend() can only be called synchronously during system suspend and we can rely on subsystems and device drivers to avoid doing that unnecessarily. Make dpm_prepare() drop the runtime PM reference to each device after making sure that runtime resume is not pending for it. Signed-off-by: Rafael J. Wysocki r...@sisk.pl --- Yes! Acked-by: Kevin Hilman khil...@ti.com Well, I hope you realize that it doesn't help you a lot? If you mean that because we still have to implement system PM methods because of /sys/devices/.../power/control, I agree. Yes, I meant that. If something else, please explain. But to me it is still very helpful in terms of consistency and what driver writers would expect to happen if they used pm_runtime_suspend() in their system suspend method. OK Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/17] timberdale: mfd_cell is now implicitly available to drivers
The cell's platform_data is now accessed with a helper function;
change clients to use that, and remove the now-unused data_size.
Note that the mfd's platform_data is marked __devinitdata. This
is still correct in all cases except for the timbgpio driver, whose
remove hook has been changed to no longer reference the pdata.
Signed-off-by: Andres Salomon dilin...@queued.net
---
drivers/dma/timb_dma.c |2 +-
drivers/gpio/timbgpio.c |5 ++---
drivers/i2c/busses/i2c-ocores.c |2 +-
drivers/i2c/busses/i2c-xiic.c|2 +-
drivers/media/radio/radio-timb.c |2 +-
drivers/media/video/timblogiw.c |2 +-
drivers/mfd/timberdale.c | 27 ---
drivers/net/ks8842.c |2 +-
drivers/spi/xilinx_spi.c |2 +-
9 files changed, 9 insertions(+), 37 deletions(-)
diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
index 3b88a4e..77bc4c2 100644
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -684,7 +684,7 @@ static irqreturn_t td_irq(int irq, void *devid)
static int __devinit td_probe(struct platform_device *pdev)
{
- struct timb_dma_platform_data *pdata = pdev-dev.platform_data;
+ struct timb_dma_platform_data *pdata = mfd_get_data(pdev);
struct timb_dma *td;
struct resource *iomem;
int irq;
diff --git a/drivers/gpio/timbgpio.c b/drivers/gpio/timbgpio.c
index 58c8f30..63527b8 100644
--- a/drivers/gpio/timbgpio.c
+++ b/drivers/gpio/timbgpio.c
@@ -228,7 +228,7 @@ static int __devinit timbgpio_probe(struct platform_device
*pdev)
struct gpio_chip *gc;
struct timbgpio *tgpio;
struct resource *iomem;
- struct timbgpio_platform_data *pdata = pdev-dev.platform_data;
+ struct timbgpio_platform_data *pdata = mfd_get_data(pdev);
int irq = platform_get_irq(pdev, 0);
if (!pdata || pdata-nr_pins 32) {
@@ -319,14 +319,13 @@ err_mem:
static int __devexit timbgpio_remove(struct platform_device *pdev)
{
int err;
- struct timbgpio_platform_data *pdata = pdev-dev.platform_data;
struct timbgpio *tgpio = platform_get_drvdata(pdev);
struct resource *iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
int irq = platform_get_irq(pdev, 0);
if (irq = 0 tgpio-irq_base 0) {
int i;
- for (i = 0; i pdata-nr_pins; i++) {
+ for (i = 0; i tgpio-gpio.ngpio; i++) {
set_irq_chip(tgpio-irq_base + i, NULL);
set_irq_chip_data(tgpio-irq_base + i, NULL);
}
diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index ef3bcb1..4b7dbc3 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -305,7 +305,7 @@ static int __devinit ocores_i2c_probe(struct
platform_device *pdev)
return -EIO;
}
- pdata = pdev-dev.platform_data;
+ pdata = mfd_get_data(pdev);
if (pdata) {
i2c-regstep = pdata-regstep;
i2c-clock_khz = pdata-clock_khz;
diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index a9c419e..f3299bb 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -704,7 +704,7 @@ static int __devinit xiic_i2c_probe(struct platform_device
*pdev)
if (irq 0)
goto resource_missing;
- pdata = (struct xiic_i2c_platform_data *) pdev-dev.platform_data;
+ pdata = mfd_get_data(pdev);
if (!pdata)
return -EINVAL;
diff --git a/drivers/media/radio/radio-timb.c b/drivers/media/radio/radio-timb.c
index a185610..d7ba57f 100644
--- a/drivers/media/radio/radio-timb.c
+++ b/drivers/media/radio/radio-timb.c
@@ -148,7 +148,7 @@ static const struct v4l2_file_operations timbradio_fops = {
static int __devinit timbradio_probe(struct platform_device *pdev)
{
- struct timb_radio_platform_data *pdata = pdev-dev.platform_data;
+ struct timb_radio_platform_data *pdata = mfd_get_data(pdev);
struct timbradio *tr;
int err;
diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
index fc611eb..5e9ca25 100644
--- a/drivers/media/video/timblogiw.c
+++ b/drivers/media/video/timblogiw.c
@@ -790,7 +790,7 @@ static int __devinit timblogiw_probe(struct platform_device
*pdev)
{
int err;
struct timblogiw *lw = NULL;
- struct timb_video_platform_data *pdata = pdev-dev.platform_data;
+ struct timb_video_platform_data *pdata = mfd_get_data(pdev);
if (!pdata) {
dev_err(pdev-dev, No platform data\n);
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 6ad8a7f..6353921 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -385,7 +385,6 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg0[] = {
.num_resources =
