Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
Hi, On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the omapdss clocks. You used clk_prepare and clk_unprepare instead of clk_prepare_enable and clk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context. What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after clk_get, or prepare right before clk_enable? (And similarly for unprepare) Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayak rna...@ti.com wrote: On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote: Hi On Fri, 22 Jun 2012, Rajendra Nayak wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() for omap gpio debounce clock. Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Grant Likelygrant.lik...@secretlab.ca --- drivers/gpio/gpio-omap.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index c4ed172..6a73b01 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -893,6 +893,8 @@ static int gpio_debounce(struct gpio_chip *chip, unsigned offset, bank-dbck = clk_get(bank-dev, dbclk); if (IS_ERR(bank-dbck)) dev_err(bank-dev, Could not get gpio dbck\n); + else + clk_prepare(bank-dbck); } spin_lock_irqsave(bank-lock, flags); What code unprepares this clock? Put differently, doesn't this driver need at least a platform_driver .remove function pointer, that would call clk_unprepare() and clk_put()? Maybe because this driver can never be built as a module. It gets complied in with CONFIG_ARCH_OMAP=y. Adding Tarun and Santosh who can comment further. Also, it looks to me that the bank-dbck init should be in omap_gpio_chip_init(), not gpio_debounce()? Tarun, can you comment on why the dbck init is in gpio_debounce and not in omap_gpio_chip_init()? BTW, bank-dbck is initialized in gpio_debounce() even before the cleanup and fixes series. I am not quite sure if there was specific intent for keeping it here. Personally I do not see issues in doing clk_get of bank-dbck in omap_gpio_chip_init(). - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
On Mon, 25 Jun 2012, Rajendra Nayak wrote: On Saturday 23 June 2012 12:04 AM, Paul Walmsley wrote: On Fri, 22 Jun 2012, S, Venkatraman wrote: On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayakrna...@ti.com wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the mmc and hsmmc clocks as part of the drivers probe() and remove() routines. Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Chris Ballc...@laptop.org Cc: Balaji T Kbalaj...@ti.com Cc:linux-...@vger.kernel.org Rajendra, Can this be applied independently, or does this patch have a dependency on other patches in the series ? A better way to handle this one would be to convert the driver to runtime PM. That needs to be done anyway. Well, mmc driver is already using runtime PM. But it still using clock apis' to deal with some optional debounce clock needed only on 2430. drivers/mmc/host/omap.c, which is what this patch changes, has not yet been converted to use runtime PM in mainline. This is a driver for the MSDI IP block which is not available on 2430. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] gpio/omap: cleanups for v3.5
On Thu, 21 Jun 2012 12:04:26 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 21, 2012 at 8:46 AM, NeilBrown ne...@suse.de wrote:
On Thu, 14 Jun 2012 23:24:10 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 14, 2012 at 5:45 AM, NeilBrown ne...@suse.de wrote:
On Fri, 11 May 2012 17:30:48 -0700 Kevin Hilman khil...@ti.com wrote:
Hi Grant,
Here's the final round of GPIO cleanups for v3.5. This branch is based
on my for_3.5/fixes/gpio branch you just pulled.
Kevin
Hi.
I'm not sure if it was this series or the following cleanups which broke
things for me, but I've been trying 3.5-rc2 on my GTA04 and the serial
console (ttyO2) dies as soon as the omap-gpio driver initialises.
After some digging I came up with this patch to gpio-omap.c
@@ -1124,6 +1124,9 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+ if (bank-get_context_loss_count)
+ bank-context_loss_count =
+ bank-get_context_loss_count(bank-dev);
pm_runtime_enable(bank-dev);
pm_runtime_irq_safe(bank-dev);
pm_runtime_get_sync(bank-dev);
which fixes it.
What was happening was that when omap_gpio_probe calls
pm_runtime_get_sync,
it calls
_od_runtime_resume - pm_generic_runtime_resume -
omap_gpio_runtime_resume
- omap_gpio_restore_context
and then the serial port stops.
I reasoned that the context probably hadn't been set up yet, so restoring
from it broke things.
Initialising bank-context_loss_count seems sensible and would ensure
that
we didn't try to restore the context until it has actually been lost.
I thought the following code exactly does that. That is
context_lost_cnt_after
would be zero until there is context loss. The bank-context_loss_count is
zero
at the beginning. So, (context_lost_cnt_after != bank-context_loss_count)
would
be false and hence context restore should NOT happen? Not sure if I am
over looking
anything here
omap_gpio_runtime_resume(...)
{
...
if (bank-get_context_loss_count) {
context_lost_cnt_after =
bank-get_context_loss_count(bank-dev);
if (context_lost_cnt_after != bank-context_loss_count) {
omap_gpio_restore_context(bank);
} else {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
}
...
}
Hi,
I've looked more closely at this now.
The problem is that the initial context loss count is *not* zero. Not
always.
The context loss count is the sum of
count = pwrdm-state_counter[PWRDM_POWER_OFF];
count += pwrdm-ret_logic_off_counter;
for (i = 0; i pwrdm-banks; i++)
count += pwrdm-ret_mem_off_counter[i];
(from pwrdm_get_context_loss_count()).
These are initlialised in _pwrdm_register
/* Initialize the powerdomain's state counter */
for (i = 0; i PWRDM_MAX_PWRSTS; i++)
pwrdm-state_counter[i] = 0;
pwrdm-ret_logic_off_counter = 0;
for (i = 0; i pwrdm-banks; i++)
pwrdm-ret_mem_off_counter[i] = 0;
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
What I'm seeing is that for wkup_pwrdm and dpll{3,4,5}_pwrdm,
the state that pwrdm_read_pwrst returns is PWRDM_POWER_OFF.
So that state_counter gets initialised to '1', and so the initial
context_loss_count, which includes that counter, is also '1'.
I think it is the wkup_pwrdm that covers the GPIOs that are causing problems
for me.
I just put a log in omap_gpio_probe() to see the value of context_loss_count.
GPIO Bank 0 (WKUP Domain) always shows the count as '1'.
[0.169494] omap_gpio omap_gpio.0: context_loss_count=1
[0.170227] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.170471] OMAP GPIO hardware version 0.1
[0.170623] omap_gpio omap_gpio.1: context_loss_count=0
[0.170928] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[0.171295] omap_gpio omap_gpio.2: context_loss_count=0
[0.171600] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[0.171936] omap_gpio omap_gpio.3: context_loss_count=0
[0.172241] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[0.172576] omap_gpio omap_gpio.4: context_loss_count=0
[0.172882] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[0.173217] omap_gpio omap_gpio.5: context_loss_count=0
[0.173522] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
That's consistent with what I see, and confirm that initialising the
context_lost_count to zero isn't
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote: From: Jassi Brar jaswinder.si...@linaro.org If the runtime PM of the device is disabled (for example in resume from suspend path), it doesn't make sense to attempt pm_runtime_get/put, esp when their return values affect the control flow path. This looks strange. When the driver does pm_runtime_get() it expects the HW to be functional and registers accessible. If we just skip the pm_runtime_get(), how can the code work? Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- Currenlty HDMI fails to come up in the suspend-resume path. This patch helps that real-world scenario. What is the problem there? It'd be good to explain the problem in the patch description. Does the pm_runtime_get return -EACCES? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: HDMI: Cache EDID
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
From: Jassi Brar jaswinder.si...@linaro.org
We can easily keep track of latest EDID from the display and hence avoid
expensive EDID re-reads over I2C.
This could also help some cheapo displays that provide EDID reliably only
immediately after asserting HPD and not later.
Even with good displays, there is something in OMAPDSS that apparantly
messes up DDC occasionally while EDID is being read, giving the
operation stopped when reading edid error.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/video/omap2/dss/hdmi.c|1 +
drivers/video/omap2/dss/ti_hdmi.h |2 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 23 ---
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 900e621..0a8c825 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -764,6 +764,7 @@ static int __init omapdss_hdmihw_probe(struct
platform_device *pdev)
hdmi.ip_data.core_av_offset = HDMI_CORE_AV;
hdmi.ip_data.pll_offset = HDMI_PLLCTRL;
hdmi.ip_data.phy_offset = HDMI_PHY;
+ hdmi.ip_data.edid_len = 0; /* Invalidate EDID Cache */
mutex_init(hdmi.ip_data.lock);
Your HDMI patches seem to depend on each other. Please post them as a
proper patch series, instead of each one separately.
hdmi_panel_init();
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index cc292b8..4735860 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -178,6 +178,8 @@ struct hdmi_ip_data {
/* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
int hpd_gpio;
struct mutex lock;
+ u8 edid_cached[256];
+ unsigned edid_len;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 04acca9..2633ade 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
if (r) {
DSSERR(Failed to %s PHY TX power\n,
@@ -454,6 +457,11 @@ int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data *ip_data,
{
int r, l;
+ if (ip_data-edid_len) {
+ memcpy(edid, ip_data-edid_cached, ip_data-edid_len);
+ return ip_data-edid_len;
+ }
+
if (len 128)
return -EINVAL;
@@ -474,12 +482,21 @@ int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data *ip_data,
l += 128;
}
+ ip_data-edid_len = l;
+ memcpy(ip_data-edid_cached, edid, l);
+
return l;
}
bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
{
- return gpio_get_value(ip_data-hpd_gpio);
+ if (gpio_get_value(ip_data-hpd_gpio))
+ return true;
+
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
+
+ return false;
Why is this needed? The HPD interrupt should handle this already. And if
the HPD interrupt doesn't work for some reason, this won't work either,
as the user can plug and unplug his HDMI monitors a thousand times
between two detect calls.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote: Hi, On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the omapdss clocks. You used clk_prepare and clk_unprepare instead of clk_prepare_enable and clk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context. What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after clk_get, or prepare right before clk_enable? (And similarly for unprepare) clk_prepare/unprepare are useful for clocks which need the 'enable' logic to be implemented as a slow part (which can sleep) and a fast part (which does not sleep). For all the dss clocks in question we don't need a slow part and hence they do not have a .clk_prepare/unprepare platform hook. The framework however still does prepare usecounting (it has a prepare count and an enable count, and prepare count is expected to be non-zero while the clock is being enabled) and uses a mutex around to guard it. So while the dss driver would do multiple clk_enable/disable while its active, it seems fair to just prepare/unprepare the clocks once just after clk_get() and before clk_put() in this particular case. Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
On Monday 25 June 2012 11:41 AM, DebBarma, Tarun Kanti wrote: On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayakrna...@ti.com wrote: On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote: Hi On Fri, 22 Jun 2012, Rajendra Nayak wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() for omap gpio debounce clock. Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Grant Likelygrant.lik...@secretlab.ca --- drivers/gpio/gpio-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index c4ed172..6a73b01 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -893,6 +893,8 @@ static int gpio_debounce(struct gpio_chip *chip, unsigned offset, bank-dbck = clk_get(bank-dev, dbclk); if (IS_ERR(bank-dbck)) dev_err(bank-dev, Could not get gpio dbck\n); + else + clk_prepare(bank-dbck); } spin_lock_irqsave(bank-lock, flags); What code unprepares this clock? Put differently, doesn't this driver need at least a platform_driver .remove function pointer, that would call clk_unprepare() and clk_put()? Maybe because this driver can never be built as a module. It gets complied in with CONFIG_ARCH_OMAP=y. Adding Tarun and Santosh who can comment further. Also, it looks to me that the bank-dbck init should be in omap_gpio_chip_init(), not gpio_debounce()? Tarun, can you comment on why the dbck init is in gpio_debounce and not in omap_gpio_chip_init()? BTW, bank-dbck is initialized in gpio_debounce() even before the cleanup and fixes series. I am not quite sure if there was specific intent for keeping it here. Personally I do not see issues in doing clk_get of bank-dbck in omap_gpio_chip_init(). Care to send a patch to move it into omap_gpio_chip_init() then? Also can you comment on the above point that Paul made, as to why this driver has a .remove missing? If adding that is a non-issue, would be great if you can drop in a patch for that too. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
On Monday 25 June 2012 11:48 AM, Paul Walmsley wrote: On Mon, 25 Jun 2012, Rajendra Nayak wrote: On Saturday 23 June 2012 12:04 AM, Paul Walmsley wrote: On Fri, 22 Jun 2012, S, Venkatraman wrote: On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayakrna...@ti.com wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the mmc and hsmmc clocks as part of the drivers probe() and remove() routines. Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Chris Ballc...@laptop.org Cc: Balaji T Kbalaj...@ti.com Cc:linux-...@vger.kernel.org Rajendra, Can this be applied independently, or does this patch have a dependency on other patches in the series ? A better way to handle this one would be to convert the driver to runtime PM. That needs to be done anyway. Well, mmc driver is already using runtime PM. But it still using clock apis' to deal with some optional debounce clock needed only on 2430. drivers/mmc/host/omap.c, which is what this patch changes, has not yet been converted to use runtime PM in mainline. Venkat/Balaji, Any plans of converting this driver to use runtime pm? This is a driver for the MSDI IP block which is not available on 2430. Sorry, I meant to say the debounce clock in omap_hsmmc.c was used only on 2430. I seemed to have overlooked the fclk/iclk in drivers/mmc /host/omap.c completely. That one seems to be for the controller in 2420 (atlest, and maybe some other older OMAPs). - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: HDMI: Cache EDID
On 25 June 2012 12:05, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
From: Jassi Brar jaswinder.si...@linaro.org
We can easily keep track of latest EDID from the display and hence avoid
expensive EDID re-reads over I2C.
This could also help some cheapo displays that provide EDID reliably only
immediately after asserting HPD and not later.
Even with good displays, there is something in OMAPDSS that apparantly
messes up DDC occasionally while EDID is being read, giving the
operation stopped when reading edid error.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/video/omap2/dss/hdmi.c | 1 +
drivers/video/omap2/dss/ti_hdmi.h | 2 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 23 ---
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 900e621..0a8c825 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -764,6 +764,7 @@ static int __init omapdss_hdmihw_probe(struct
platform_device *pdev)
hdmi.ip_data.core_av_offset = HDMI_CORE_AV;
hdmi.ip_data.pll_offset = HDMI_PLLCTRL;
hdmi.ip_data.phy_offset = HDMI_PHY;
+ hdmi.ip_data.edid_len = 0; /* Invalidate EDID Cache */
mutex_init(hdmi.ip_data.lock);
Your HDMI patches seem to depend on each other. Please post them as a
proper patch series, instead of each one separately.
They don't depend functionality wise. Any fix can be accepted
regardless of others.
I deliberately avoided a series, because revision of just one could
require resending 3, otherwise
perfectly OK, patches. I just wanted to limit the noise.
I understand, 'git am' might complain but I think that should be trivial to fix.
I am perfectly OK to resend as a patch series, if you want.
hdmi_panel_init();
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index cc292b8..4735860 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -178,6 +178,8 @@ struct hdmi_ip_data {
/* ti_hdmi_4xxx_ip private data. These should be in a separate struct
*/
int hpd_gpio;
struct mutex lock;
+ u8 edid_cached[256];
+ unsigned edid_len;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 04acca9..2633ade 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
if (r) {
DSSERR(Failed to %s PHY TX power\n,
@@ -454,6 +457,11 @@ int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data *ip_data,
{
int r, l;
+ if (ip_data-edid_len) {
+ memcpy(edid, ip_data-edid_cached, ip_data-edid_len);
+ return ip_data-edid_len;
+ }
+
if (len 128)
return -EINVAL;
@@ -474,12 +482,21 @@ int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data
*ip_data,
l += 128;
}
+ ip_data-edid_len = l;
+ memcpy(ip_data-edid_cached, edid, l);
+
return l;
}
bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
{
- return gpio_get_value(ip_data-hpd_gpio);
+ if (gpio_get_value(ip_data-hpd_gpio))
+ return true;
+
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
+
+ return false;
Why is this needed? The HPD interrupt should handle this already. And if
the HPD interrupt doesn't work for some reason, this won't work either,
as the user can plug and unplug his HDMI monitors a thousand times
between two detect calls.
I thought it is almost impossible to unplug-plug cycle the HDMI cable
even twice a second, let alone 1000 times against the 10Hz .detect()
poll :)Or you mean some relay controlled HDMI switching
mechanism?
Anyways, that is not the point of this patch. This patch only aims to
avoid un-ncessary EDID reads while doing its best to make sure we
invalidate EDID 'as soon as possible'.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote: On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote: Hi, On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the omapdss clocks. You used clk_prepare and clk_unprepare instead of clk_prepare_enable and clk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context. What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after clk_get, or prepare right before clk_enable? (And similarly for unprepare) clk_prepare/unprepare are useful for clocks which need the 'enable' logic to be implemented as a slow part (which can sleep) and a fast part (which does not sleep). For all the dss clocks in question we don't need a slow part and hence they do not have a .clk_prepare/unprepare platform hook. The framework however still does prepare usecounting (it has a prepare count and an enable count, and prepare count is expected to be non-zero while the clock is being enabled) and uses a mutex around to guard it. So while the dss driver would do multiple clk_enable/disable while its active, it seems fair to just prepare/unprepare the clocks once just after clk_get() and before clk_put() in this particular case. But the driver should not presume anything special about the clocks. In this case the dss driver would presume that the clocks it uses do not have prepare and unprepare hooks. If the generally proper way to use prepare/unprepare is in combination of enable/disable, then I think we should try to do that. I'll check if any of the dss clocks are enabled or disabled in atomic context. Tomi signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] gpio/omap: cleanups for v3.5
On Mon, Jun 25, 2012 at 11:48 AM, NeilBrown ne...@suse.de wrote:
On Thu, 21 Jun 2012 12:04:26 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 21, 2012 at 8:46 AM, NeilBrown ne...@suse.de wrote:
On Thu, 14 Jun 2012 23:24:10 +0530 DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Jun 14, 2012 at 5:45 AM, NeilBrown ne...@suse.de wrote:
On Fri, 11 May 2012 17:30:48 -0700 Kevin Hilman khil...@ti.com wrote:
Hi Grant,
Here's the final round of GPIO cleanups for v3.5. This branch is based
on my for_3.5/fixes/gpio branch you just pulled.
Kevin
Hi.
I'm not sure if it was this series or the following cleanups which
broke
things for me, but I've been trying 3.5-rc2 on my GTA04 and the serial
console (ttyO2) dies as soon as the omap-gpio driver initialises.
After some digging I came up with this patch to gpio-omap.c
@@ -1124,6 +1124,9 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bank);
+ if (bank-get_context_loss_count)
+ bank-context_loss_count =
+ bank-get_context_loss_count(bank-dev);
pm_runtime_enable(bank-dev);
pm_runtime_irq_safe(bank-dev);
pm_runtime_get_sync(bank-dev);
which fixes it.
What was happening was that when omap_gpio_probe calls
pm_runtime_get_sync,
it calls
_od_runtime_resume - pm_generic_runtime_resume -
omap_gpio_runtime_resume
- omap_gpio_restore_context
and then the serial port stops.
I reasoned that the context probably hadn't been set up yet, so
restoring
from it broke things.
Initialising bank-context_loss_count seems sensible and would ensure
that
we didn't try to restore the context until it has actually been lost.
I thought the following code exactly does that. That is
context_lost_cnt_after
would be zero until there is context loss. The bank-context_loss_count
is zero
at the beginning. So, (context_lost_cnt_after !=
bank-context_loss_count) would
be false and hence context restore should NOT happen? Not sure if I am
over looking
anything here
omap_gpio_runtime_resume(...)
{
...
if (bank-get_context_loss_count) {
context_lost_cnt_after =
bank-get_context_loss_count(bank-dev);
if (context_lost_cnt_after != bank-context_loss_count) {
omap_gpio_restore_context(bank);
} else {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
}
...
}
Hi,
I've looked more closely at this now.
The problem is that the initial context loss count is *not* zero. Not
always.
The context loss count is the sum of
count = pwrdm-state_counter[PWRDM_POWER_OFF];
count += pwrdm-ret_logic_off_counter;
for (i = 0; i pwrdm-banks; i++)
count += pwrdm-ret_mem_off_counter[i];
(from pwrdm_get_context_loss_count()).
These are initlialised in _pwrdm_register
/* Initialize the powerdomain's state counter */
for (i = 0; i PWRDM_MAX_PWRSTS; i++)
pwrdm-state_counter[i] = 0;
pwrdm-ret_logic_off_counter = 0;
for (i = 0; i pwrdm-banks; i++)
pwrdm-ret_mem_off_counter[i] = 0;
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
What I'm seeing is that for wkup_pwrdm and dpll{3,4,5}_pwrdm,
the state that pwrdm_read_pwrst returns is PWRDM_POWER_OFF.
So that state_counter gets initialised to '1', and so the initial
context_loss_count, which includes that counter, is also '1'.
I think it is the wkup_pwrdm that covers the GPIOs that are causing
problems
for me.
I just put a log in omap_gpio_probe() to see the value of context_loss_count.
GPIO Bank 0 (WKUP Domain) always shows the count as '1'.
[ 0.169494] omap_gpio omap_gpio.0: context_loss_count=1
[ 0.170227] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[ 0.170471] OMAP GPIO hardware version 0.1
[ 0.170623] omap_gpio omap_gpio.1: context_loss_count=0
[ 0.170928] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[ 0.171295] omap_gpio omap_gpio.2: context_loss_count=0
[ 0.171600] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[ 0.171936] omap_gpio omap_gpio.3: context_loss_count=0
[ 0.172241] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[ 0.172576] omap_gpio omap_gpio.4: context_loss_count=0
[ 0.172882] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[ 0.173217] omap_gpio omap_gpio.5: context_loss_count=0
[ 0.173522] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
That's consistent with what
Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP
On Mon, Jun 25, 2012 at 2:51 AM, Shawn Guo shawn@linaro.org wrote: It seems the same patch has been there for a while. http://thread.gmane.org/gmane.linux.kernel/1303115 Regards, Shawn Hi Shawn, Thanks for the info, I first send this patch: http://www.spinics.net/lists/linux-omap/msg72489.html but Russell pointed me to the thread: http://lists.arm.linux.org.uk/lurker/thread/20120523.200015.2fdfd505.en.html and told me that no patch ever came from his response on the subject. That's why I sent this patch with Russell suggested approach to solve the issue. But as you said, it was sent but got lost. That's a pity since the bug is pretty serious (it deterministically crashes when trying to reboot the board). Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: HDMI: Cache EDID
On Mon, 2012-06-25 at 13:26 +0530, Jassi Brar wrote:
On 25 June 2012 12:05, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
From: Jassi Brar jaswinder.si...@linaro.org
We can easily keep track of latest EDID from the display and hence avoid
expensive EDID re-reads over I2C.
This could also help some cheapo displays that provide EDID reliably only
immediately after asserting HPD and not later.
Even with good displays, there is something in OMAPDSS that apparantly
messes up DDC occasionally while EDID is being read, giving the
operation stopped when reading edid error.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/video/omap2/dss/hdmi.c|1 +
drivers/video/omap2/dss/ti_hdmi.h |2 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 23 ---
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c
b/drivers/video/omap2/dss/hdmi.c
index 900e621..0a8c825 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -764,6 +764,7 @@ static int __init omapdss_hdmihw_probe(struct
platform_device *pdev)
hdmi.ip_data.core_av_offset = HDMI_CORE_AV;
hdmi.ip_data.pll_offset = HDMI_PLLCTRL;
hdmi.ip_data.phy_offset = HDMI_PHY;
+ hdmi.ip_data.edid_len = 0; /* Invalidate EDID Cache */
mutex_init(hdmi.ip_data.lock);
Your HDMI patches seem to depend on each other. Please post them as a
proper patch series, instead of each one separately.
They don't depend functionality wise. Any fix can be accepted
regardless of others.
I deliberately avoided a series, because revision of just one could
require resending 3, otherwise
perfectly OK, patches. I just wanted to limit the noise.
You don't need to send the whole series, you can just send a revised
patch as a reply to the older version of that patch. (see --in-reply-to
of git send-email).
Of course if you end up changing many of the patches, or one patch lots
of times, it is good to send the whole series at some point later when
the patches have stabilized.
I understand, 'git am' might complain but I think that should be trivial to
fix.
I'd rather not spend time doing trivial fixes, or trying to find latest
versions of individual patches that have dependencies. Having the
patches in a series and replying with new versions to the older versions
makes my life much easier. I'll see all of them in my email client in
one bunch, properly sorted.
I am perfectly OK to resend as a patch series, if you want.
Yes please.
bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
{
- return gpio_get_value(ip_data-hpd_gpio);
+ if (gpio_get_value(ip_data-hpd_gpio))
+ return true;
+
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
+
+ return false;
Why is this needed? The HPD interrupt should handle this already. And if
the HPD interrupt doesn't work for some reason, this won't work either,
as the user can plug and unplug his HDMI monitors a thousand times
between two detect calls.
I thought it is almost impossible to unplug-plug cycle the HDMI cable
even twice a second, let alone 1000 times against the 10Hz .detect()
poll :)Or you mean some relay controlled HDMI switching
mechanism?
omapdss doesn't call the detect function, so it can't presume it's used
in some certain frequency. Also, last time I tested omapdrm, I think
detect was called once in 5 secs or so.
Anyways, that is not the point of this patch. This patch only aims to
avoid un-ncessary EDID reads while doing its best to make sure we
invalidate EDID 'as soon as possible'.
I'm not sure I understand your point. If the HPD interrupt works
properly, EDID is invalidated there, and the code in detect is not
needed. And if the HPD interrupt doesn't work (although I don't see why
it wouldn't), the code in detect doesn't work. In either case it's not
correct.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP
On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote: It seems the same patch has been there for a while. http://thread.gmane.org/gmane.linux.kernel/1303115 Bah, why doesn't stuff like this get resent if nothing has happened for a while? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On 25 June 2012 11:50, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote: Currenlty HDMI fails to come up in the suspend-resume path. This patch helps that real-world scenario. What is the problem there? It'd be good to explain the problem in the patch description. Does the pm_runtime_get return -EACCES? Yes, it returns -EACCESS because RPM on devices is disabled during the period from suspend-start to resume-finished. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] mfd: omap-usb: add clk_prepare and clk_unprepare
On Sat, Jun 23, 2012 at 12:34 AM, Paul Walmsley p...@pwsan.com wrote: On Fri, 22 Jun 2012, Rajendra Nayak wrote: In preparation of OMAP moving to Common Clk Framework (CCF) add clk_prepare() and clk_unprepare() for the various usb host clocks. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Looks like this one will be at least partially obsoleted by this series: Thanks paul Hi Rajendra please re-base this patch to below series: ARM: OMAP: TLL driver implementation for USB host driver http://marc.info/?l=linux-omapm=134019432606399w=2 and the runtime PM conversion in that series needs to be done anyway. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: HDMI: Cache EDID
On 25 June 2012 13:41, Tomi Valkeinen tomi.valkei...@ti.com wrote:
I am perfectly OK to resend as a patch series, if you want.
Yes please.
OK, will do.
bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
{
- return gpio_get_value(ip_data-hpd_gpio);
+ if (gpio_get_value(ip_data-hpd_gpio))
+ return true;
+
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
+
+ return false;
Why is this needed? The HPD interrupt should handle this already. And if
the HPD interrupt doesn't work for some reason, this won't work either,
as the user can plug and unplug his HDMI monitors a thousand times
between two detect calls.
I thought it is almost impossible to unplug-plug cycle the HDMI cable
even twice a second, let alone 1000 times against the 10Hz .detect()
poll :) Or you mean some relay controlled HDMI switching
mechanism?
omapdss doesn't call the detect function, so it can't presume it's used
in some certain frequency. Also, last time I tested omapdrm, I think
detect was called once in 5 secs or so.
It's not omapdss. It's the DRM stack, via the omapdrm, that polls
every 10 secs (not 5).
Sorry I said 10Hz instead of 1/10Hz.
Anyways, that is not the point of this patch. This patch only aims to
avoid un-ncessary EDID reads while doing its best to make sure we
invalidate EDID 'as soon as possible'.
I'm not sure I understand your point. If the HPD interrupt works
properly, EDID is invalidated there, and the code in detect is not
needed. And if the HPD interrupt doesn't work (although I don't see why
it wouldn't), the code in detect doesn't work. In either case it's not
correct.
Well, the idea was to tie edid-cache invalidating with de-asserted
HPD, wherever we read HPD. I will drop it.
thnx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Mon, 2012-06-25 at 14:19 +0530, Jassi Brar wrote: On 25 June 2012 11:50, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote: Currenlty HDMI fails to come up in the suspend-resume path. This patch helps that real-world scenario. What is the problem there? It'd be good to explain the problem in the patch description. Does the pm_runtime_get return -EACCES? Yes, it returns -EACCESS because RPM on devices is disabled during the period from suspend-start to resume-finished. So... You didn't answer my first comment, how can the code work? The driver needs to enable the HW and the call to pm_runtime_get() is skipped. Won't this lead to crash as the DSS registers are accessed without the HW in enabled state? And what happens if the pm_runtime_get() call is skipped, but pm_runtime_put() is not? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/2] ARM: OMAP2: Fix tusb6010 GPIO interrupt for n8x0
On Wed, Jun 13, 2012 at 03:15:12AM -0700, Tony Lindgren wrote:
Here's one more gpio_to_irq conversion that we missed
earlier. Tested with n800 in gadget mode using USB_ETH.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index db84a46..805bea6 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -300,7 +300,7 @@ tusb6010_setup_interface(struct musb_hdrc_platform_data
*data,
printk(error, 3, status);
return status;
}
- tusb_resources[2].start = irq + IH_GPIO_BASE;
+ tusb_resources[2].start = gpio_to_irq(irq);
/* set up memory timings ... can speed them up later */
if (!ps_refclk) {
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] spi: omap2-mcspi: fix section mismatch regression in probe
On Tue, Jun 19, 2012 at 03:27:48PM +0530, Venkatraman S wrote:
Commit 7d6b6d83(make it behave as a module) annotated probe with
__devinit, but a referenced function was not.
This introduced a section mismatch warning:
WARNING: vmlinux.o(.devinit.text+0x3eec): Section mismatch in reference
from the function omap2_mcspi_probe() to the function
.init.text:omap2_mcspi_master_setup()
Signed-off-by: Venkatraman S svenk...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
my apologies
---
drivers/spi/spi-omap2-mcspi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 46ef5fe..1618e89 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1031,7 +1031,7 @@ static int omap2_mcspi_transfer_one_message(struct
spi_master *master,
return 0;
}
-static int __init omap2_mcspi_master_setup(struct omap2_mcspi *mcspi)
+static int __devinit omap2_mcspi_master_setup(struct omap2_mcspi *mcspi)
{
struct spi_master *master = mcspi-master;
struct omap2_mcspi_regs *ctx = mcspi-ctx;
--
1.7.0.4
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv9 3/8] I2C: OMAP: use devm_* functions
On Thu, Jun 21, 2012 at 03:38:44PM +0530, Shubhrajyoti D wrote:
The various devm_* functions allocate memory that is released when a driver
detaches. This patch uses devm_kzalloc, devm_request_and_ioremap for data
that is allocated in the probe function of a platform device and is only
freed in the remove function.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
this looks a lot like:
http://marc.info/?l=linux-omapm=133969143407572w=2
I wonder why wasn't that one used instead ?
---
drivers/i2c/busses/i2c-omap.c | 33 +
1 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d704f64..328a022 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -943,7 +943,7 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq, *ioarea;
+ struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
@@ -962,17 +962,16 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- ioarea = request_mem_region(mem-start, resource_size(mem),
- pdev-name);
- if (!ioarea) {
- dev_err(pdev-dev, I2C region already claimed\n);
- return -EBUSY;
+ dev = devm_kzalloc(pdev-dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(pdev-dev, Menory allocation failed\n);
+ return -ENOMEM;
}
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
- if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev-base = devm_request_and_ioremap(pdev-dev, mem);
+ if (!dev-base) {
+ dev_err(pdev-dev, I2C region already claimed\n);
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
@@ -996,11 +995,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dev = pdev-dev;
dev-irq = irq-start;
- dev-base = ioremap(mem-start, resource_size(mem));
- if (!dev-base) {
- r = -ENOMEM;
- goto err_free_mem;
- }
platform_set_drvdata(pdev, dev);
@@ -1095,13 +1089,9 @@ err_free_irq:
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev-dev);
- iounmap(dev-base);
pm_runtime_disable(pdev-dev);
err_free_mem:
platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem-start, resource_size(mem));
return r;
}
@@ -1109,7 +1099,6 @@ err_release_region:
static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
int ret;
platform_set_drvdata(pdev, NULL);
@@ -1123,10 +1112,6 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
- iounmap(dev-base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
return 0;
}
--
1.7.5.4
--
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
On Mon, Jun 25, 2012 at 12:32 PM, Rajendra Nayak rna...@ti.com wrote: On Monday 25 June 2012 11:41 AM, DebBarma, Tarun Kanti wrote: On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayakrna...@ti.com wrote: On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote: Hi On Fri, 22 Jun 2012, Rajendra Nayak wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() for omap gpio debounce clock. Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Grant Likelygrant.lik...@secretlab.ca --- drivers/gpio/gpio-omap.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index c4ed172..6a73b01 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -893,6 +893,8 @@ static int gpio_debounce(struct gpio_chip *chip, unsigned offset, bank-dbck = clk_get(bank-dev, dbclk); if (IS_ERR(bank-dbck)) dev_err(bank-dev, Could not get gpio dbck\n); + else + clk_prepare(bank-dbck); } spin_lock_irqsave(bank-lock, flags); What code unprepares this clock? Put differently, doesn't this driver need at least a platform_driver .remove function pointer, that would call clk_unprepare() and clk_put()? Maybe because this driver can never be built as a module. It gets complied in with CONFIG_ARCH_OMAP=y. Adding Tarun and Santosh who can comment further. Also, it looks to me that the bank-dbck init should be in omap_gpio_chip_init(), not gpio_debounce()? Tarun, can you comment on why the dbck init is in gpio_debounce and not in omap_gpio_chip_init()? BTW, bank-dbck is initialized in gpio_debounce() even before the cleanup and fixes series. I am not quite sure if there was specific intent for keeping it here. Personally I do not see issues in doing clk_get of bank-dbck in omap_gpio_chip_init(). Care to send a patch to move it into omap_gpio_chip_init() then? Also can you comment on the above point that Paul made, as to why this driver has a .remove missing? If adding that is a non-issue, would be great if you can drop in a patch for that too. Yes, I will have a re-look before generating the patches. -- Tarun - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: fix naming collision of variable nr_irqs
Using nr_irqs as local variable name triggers the sparse warning..
./arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'nr_irqs' shadows an earlier
one
./linux/include/linux/irqnr.h:26:12: originally declared here
Signed-off-by: Venkatraman S svenk...@ti.com
---
arch/arm/mach-omap2/irq.c|8
arch/arm/mach-omap2/prm_common.c |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 6038a8c..4c35366 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -262,7 +262,7 @@ int __init omap_intc_of_init(struct device_node *node,
struct device_node *parent)
{
struct resource res;
- u32 nr_irqs = 96;
+ u32 nr_irq = 96;
if (WARN_ON(!node))
return -ENODEV;
@@ -272,10 +272,10 @@ int __init omap_intc_of_init(struct device_node *node,
return -EINVAL;
}
- if (of_property_read_u32(node, ti,intc-size, nr_irqs))
- pr_warn(unable to get intc-size, default to %d\n, nr_irqs);
+ if (of_property_read_u32(node, ti,intc-size, nr_irq))
+ pr_warn(unable to get intc-size, default to %d\n, nr_irq);
- omap_init_irq(res.start, nr_irqs, of_node_get(node));
+ omap_init_irq(res.start, nr_irq, of_node_get(node));
return 0;
}
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index dfe00dd..534d732 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -85,7 +85,7 @@ static void omap_prcm_irq_handler(unsigned int irq, struct
irq_desc *desc)
unsigned long priority_pending[OMAP_PRCM_MAX_NR_PENDING_REG];
struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned int virtirq;
- int nr_irqs = prcm_irq_setup-nr_regs * 32;
+ int nr_irq = prcm_irq_setup-nr_regs * 32;
/*
* If we are suspended, mask all interrupts from PRCM level,
@@ -110,7 +110,7 @@ static void omap_prcm_irq_handler(unsigned int irq, struct
irq_desc *desc)
prcm_irq_setup-read_pending_irqs(pending);
/* No bit set, then all IRQs are handled */
- if (find_first_bit(pending, nr_irqs) = nr_irqs)
+ if (find_first_bit(pending, nr_irq) = nr_irq)
break;
omap_prcm_events_filter_priority(pending, priority_pending);
@@ -121,11 +121,11 @@ static void omap_prcm_irq_handler(unsigned int irq,
struct irq_desc *desc)
*/
/* Serve priority events first */
- for_each_set_bit(virtirq, priority_pending, nr_irqs)
+ for_each_set_bit(virtirq, priority_pending, nr_irq)
generic_handle_irq(prcm_irq_setup-base_irq + virtirq);
/* Serve normal events next */
- for_each_set_bit(virtirq, pending, nr_irqs)
+ for_each_set_bit(virtirq, pending, nr_irq)
generic_handle_irq(prcm_irq_setup-base_irq + virtirq);
}
if (chip-irq_ack)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP2+: use proper type for keymap data in boardfiles.
This fixes the sparse warnings...
arch/arm/mach-omap2/board-igep0020.c:482:14:
warning: incorrect type in initializer (different signedness)
arch/arm/mach-omap2/board-4430sdp.c:200:14:
warning: incorrect type in initializer (different signedness)
Signed-off-by: Venkatraman S svenk...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 8e17284..af7be39 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -64,7 +64,7 @@
#define GPIO_WIFI_PMENA54
#define GPIO_WIFI_IRQ 53
-static const int sdp4430_keymap[] = {
+static const uint32_t sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
KEY(0, 1, KEY_R),
KEY(0, 2, KEY_T),
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 7491529..c138944 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -459,7 +459,7 @@ static struct platform_device *igep_devices[] __initdata = {
igep_vwlan_device,
};
-static int igep2_keymap[] = {
+static const uint32_t igep2_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
KEY(0, 2, KEY_A),
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 3/8] I2C: OMAP: use devm_* functions
On Mon, Jun 25, 2012 at 3:21 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Jun 21, 2012 at 03:38:44PM +0530, Shubhrajyoti D wrote: The various devm_* functions allocate memory that is released when a driver detaches. This patch uses devm_kzalloc, devm_request_and_ioremap for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com this looks a lot like: http://marc.info/?l=linux-omapm=133969143407572w=2 I wonder why wasn't that one used instead ? Indeed will drop this one from the series. In fact, missed the irq part. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP
On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote: It seems the same patch has been there for a while. http://thread.gmane.org/gmane.linux.kernel/1303115 Bah, why doesn't stuff like this get resent if nothing has happened for a while? Indeed. At least other people that face the same issue (like me) sends similar patches to remind you :-) Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Fix MUSB ifdefs for platform init code
* Felipe Balbi ba...@ti.com [120622 03:22]: On Wed, Jun 13, 2012 at 03:15:06AM -0700, Tony Lindgren wrote: Commit 62285963 (usb: musb: drop a gigantic amount of ifdeferry) got rid of a bunch of ifdefs in the MUSB code. Looks like the platform init code is still using these dropped defines though, which in many cases results the board defaulting always to host mode. Currently the situation is that USB_MUSB_HDRC is the main Kconfig option with additional USB_GADGET_MUSB_HDRC so only these two should be used to select between host and OTG mode. Fix the situation for omaps. The following users should fix the platform init code in a similar way: Dropped Kconfig option Current users USB_MUSB_OTGblackfin, davinci, not in Kconfigs USB_MUSB_PERIPHERAL davinci, not in Kconfigs USB_MUSB_HOST davinci, not in Kconfigs USB_MUSB_HDRC_HCD blackfin, not in Kconfigs USB_MUSB_OTGblackfin, not in Kconfigs Cc: Mike Frysinger vap...@gentoo.org Cc: Sekhar Nori nsek...@ti.com Cc: linux-...@vger.kernel.org Cc: Felipe Balbi ba...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com Looks ok, though I would stick to things boards are wired to do. e.g.: all development boards are wired for OTG (with a few exceptions), n800 is peripheral only n810 is OTG and so on. That way you remove all the clutter. FYI, these got already merged last week as fixes because of the broken Kconfig options. What you're suggesting sounds like a good follow-up patch to improve things, although I suggest that we remove CONFIG_USB_GADGET_MUSB_HDRC ifdef else from board-*.c files, and always set host = MUSB_OTG. For example, both n800 and n810 are wired up the same way except for the mini-B vs mini-AB connector. The connector alone should be enough to keep n800 as peripheral unless somebody specifically wants to force it into host mode by using a non-standard cable or the debug options. AFAIK, this same logic should apply to all the devices, or do you see issues with it? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap4: Fix standalone OMAP4 build break
* Rajendra Nayak rna...@ti.com [120622 04:48]:
Fix the below build error while building OMAP4 standalone
CC arch/arm/mach-omap2/board-flash.o
arch/arm/mach-omap2/board-flash.c:102: error: redefinition of
'board_onenand_init'
arch/arm/mach-omap2/board-flash.h:56: note: previous definition of
'board_onenand_init' was here
make[1]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Rajendra Nayak rna...@ti.com
Thanks, applying into fixes with the updated description to describe
the regression causing commit.
Tony
---
arch/arm/mach-omap2/board-flash.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..53c39d2 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -97,11 +97,6 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(board_onenand_data);
}
-#else
-void
-__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8
cs)
-{
-}
#endif /* CONFIG_MTD_ONENAND_OMAP2 || CONFIG_MTD_ONENAND_OMAP2_MODULE */
#if defined(CONFIG_MTD_NAND_OMAP2) || \
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Fix MUSB ifdefs for platform init code
Hi, On Mon, Jun 25, 2012 at 03:47:20AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [120622 03:22]: On Wed, Jun 13, 2012 at 03:15:06AM -0700, Tony Lindgren wrote: Commit 62285963 (usb: musb: drop a gigantic amount of ifdeferry) got rid of a bunch of ifdefs in the MUSB code. Looks like the platform init code is still using these dropped defines though, which in many cases results the board defaulting always to host mode. Currently the situation is that USB_MUSB_HDRC is the main Kconfig option with additional USB_GADGET_MUSB_HDRC so only these two should be used to select between host and OTG mode. Fix the situation for omaps. The following users should fix the platform init code in a similar way: Dropped Kconfig option Current users USB_MUSB_OTGblackfin, davinci, not in Kconfigs USB_MUSB_PERIPHERAL davinci, not in Kconfigs USB_MUSB_HOST davinci, not in Kconfigs USB_MUSB_HDRC_HCD blackfin, not in Kconfigs USB_MUSB_OTGblackfin, not in Kconfigs Cc: Mike Frysinger vap...@gentoo.org Cc: Sekhar Nori nsek...@ti.com Cc: linux-...@vger.kernel.org Cc: Felipe Balbi ba...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com Looks ok, though I would stick to things boards are wired to do. e.g.: all development boards are wired for OTG (with a few exceptions), n800 is peripheral only n810 is OTG and so on. That way you remove all the clutter. FYI, these got already merged last week as fixes because of the broken Kconfig options. What you're suggesting sounds like a good follow-up patch to improve things, although I suggest that we remove CONFIG_USB_GADGET_MUSB_HDRC ifdef else from board-*.c files, and always set host = MUSB_OTG. For example, both n800 and n810 are wired up the same way except for the mini-B vs mini-AB connector. The connector alone should be enough to keep n800 as peripheral unless somebody specifically wants to force it into host mode by using a non-standard cable or the debug options. AFAIK, this same logic should apply to all the devices, or do you see issues with it? no, that's pretty much what I tried to say ;-) If board has a mini/micro-B receptacle, then it can't be host/OTG/DRD (unless you hack the cable, or change ID pin rules on the transceiver, or you force the IP to host mode through the testmode register). Now if board has mini/micro-AB, then it's surely supporting OTG, so we can set board_file to MUSB_OTG. That will drop all ifdeferry too. -- balbi signature.asc Description: Digital signature
[PATCHv10 3/7] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d704f64..c771c28 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1130,6 +1130,7 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
#ifdef CONFIG_PM_RUNTIME
static void omap_i2c_restore(struct omap_i2c_dev *dev)
{
@@ -1191,15 +1192,16 @@ static int omap_i2c_runtime_resume(struct device *dev)
return 0;
}
+#endif /* CONFIG_PM_RUNTIME */
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
#else
#define OMAP_I2C_PM_OPS NULL
-#endif
+#endif /* CONFIG_PM */
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
--
1.7.5.4
--
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
[PATCHv9 0/7] I2C cleanups
The patch series does the following - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - Adds a pdata function pointer to do context save restore - Split the omap_i2c_isr to increase readability - Make the i2c use SET_RUNTIME_PM_OPS - Use INIT_COMPLETION instead of init_completion - the reset patch is dropped will try to rework it as per the review comments recieved. This applies on Wolfram's i2c-embedded/for-next branch. Functional testing on omap4430 , 4460 panda and omap3sdp. Previous discurssions http://www.spinics.net/lists/linux-i2c/msg07748.html This series mainly is the cleanups rebased on i2c-embedded/for-next branch. Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (5): I2C: OMAP: I2C register restore only if context is lost I2C: OMAP: Optimise the remove code I2C: OMAP: Use SET_RUNTIME_PM_OPS I2C: OMAP: Do not initialise the completion everytime I2C: OMAP: Remove the definition of SYSS_RESETDONE_MASK Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition arch/arm/plat-omap/i2c.c |3 + drivers/i2c/busses/i2c-omap.c | 95 + include/linux/i2c-omap.h |1 + 3 files changed, 72 insertions(+), 27 deletions(-) -- 1.7.5.4 -- 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
[PATCHv10 7/7] I2C: OMAP: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0.
I acknowledge the contributions and suggestions of Jon and Hemant.
A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and typically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0557b0d..421dcd7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -148,16 +148,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
@@ -460,6 +459,29 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, (OMAP_I2C_SYSTEST_ST_EN
+ | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
/*
* Low level master read/write transaction.
@@ -586,6 +608,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
@@ -654,6 +678,7 @@ static inline void i2c_omap_errata_i207(struct omap_i2c_dev
*dev, u16 stat)
}
}
+ return 0;
}
/* rev1 devices are apparently only on some 15xx */
--
1.7.5.4
--
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
[PATCHv10 6/7] I2C: OMAP: Correct I2C revision for OMAP3
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8344ad030..0557b0d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -50,8 +50,8 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
-#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_3530_4430 0x40
+#define OMAP_I2C_REV_ON_3430_3530 0x3C
+#define OMAP_I2C_REV_ON_3630_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -305,7 +305,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
@@ -1021,7 +1021,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207)
dev-errata |= I2C_OMAP_ERRATA_I207;
- if (dev-rev = OMAP_I2C_REV_ON_3430)
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1039,7 +1039,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+ if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
--
1.7.5.4
--
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
[PATCHv10 1/7] I2C: OMAP: I2C register restore only if context is lost
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost
or in case of error to be on the safe side.
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c |3 +++
drivers/i2c/busses/i2c-omap.c | 35 ++-
include/linux/i2c-omap.h |1 +
3 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index db071bc..4ccab07 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id)
*/
if (cpu_is_omap34xx())
pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
+
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9895fa7..9a54e88 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,6 +43,7 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
+#include plat/omap_device.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -185,6 +186,7 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*get_context_loss_count)(struct device *dev);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -207,6 +209,7 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
+ int dev_lost_count;
};
static const u8 reg_map_ip_v1[] = {
@@ -987,6 +990,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-speed = pdata-clkrate;
dev-flags = pdata-flags;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
+ dev-get_context_loss_count = pdata-get_context_loss_count;
dev-dtrev = pdata-rev;
}
@@ -1128,12 +1132,26 @@ omap_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_RUNTIME
+static void omap_i2c_restore(struct omap_i2c_dev *dev)
+{
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+
+}
static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
u16 iv;
+ if (_dev-get_context_loss_count)
+ _dev-dev_lost_count = _dev-get_context_loss_count(dev);
+
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
@@ -1154,16 +1172,15 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ int loss_cnt;
+
+ if (!(_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE))
+ return 0;
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ if (_dev-get_context_loss_count) {
+ loss_cnt = _dev-get_context_loss_count(dev);
+ if (_dev-dev_lost_count != loss_cnt)
+ omap_i2c_restore(_dev);
}
/*
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index 92a0dc7..c76cbc0 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@
[PATCHv10 5/7] I2C: OMAP: Remove the definition of SYSS_RESETDONE_MASK
Remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Also fixes the warning
CC drivers/i2c/busses/i2c-omap.o
drivers/i2c/busses/i2c-omap.c:163: warning: SYSS_RESETDONE_MASK redefined
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f1109f4..8344ad030 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -159,9 +159,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
#endif
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK(1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
#define SYSC_SIDLEMODE_MASK(0x3 3)
--
1.7.5.4
--
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
[PATCHv10 2/7] I2C: OMAP: Optimise the remove code
The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9a54e88..d704f64 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1106,8 +1106,7 @@ err_release_region:
return r;
}
-static int
-omap_i2c_remove(struct platform_device *pdev)
+static int __devexit omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
struct resource *mem;
@@ -1204,7 +1203,7 @@ static struct dev_pm_ops omap_i2c_pm_ops = {
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
- .remove = omap_i2c_remove,
+ .remove = __devexit_p(omap_i2c_remove),
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
--
1.7.5.4
--
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
[PATCHv10 4/7] I2C: OMAP: Do not initialise the completion everytime
Use INIT_COMPLETION instead of init_completion in transfer. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index c771c28..f1109f4 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -493,7 +493,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, w |= OMAP_I2C_BUF_RXFIF_CLR | OMAP_I2C_BUF_TXFIF_CLR; omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, w); - init_completion(dev-cmd_complete); + INIT_COMPLETION(dev-cmd_complete); dev-cmd_err = 0; w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT; @@ -1003,6 +1003,7 @@ omap_i2c_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, dev); + init_completion(dev-cmd_complete); dev-reg_shift = (dev-flags OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) 3; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] Add cyclic DMA support to OMAP DMA engine driver
On Fri, Jun 22, 2012 at 05:11:56PM +0100, Mark Brown wrote: On Fri, Jun 22, 2012 at 02:17:51PM +0100, Russell King - ARM Linux wrote: I suspect the key difference is I run the uImage kernels on the SDP4430 without a DT blob. I suspect it's the DT conversion of sound/soc/omap that's buggered it up. This sounds like the most likely explanation. There's not that many commits, would it be possible for you to try bisecting them (or just reverting them one at a time)? The most salient ones should be: 356bccbea17988bd32a016ada867dd6a53ba2796 ASoC: omap-abe-twl6040: Introduce driver data for runtime parameters 7d09f9e98956b29755f20d830252dec9300e7044 ASoC: omap-abe-twl6040: Move Digital Mic widget into dapm table c2f98956e3635a897737cc08a60539752aa00dd7 ASoC: omap-abe-twl6040: Keep only one snd_soc_dai_link structure though it looks like a bisect of sound/soc/omap should be about as fast. Like I say if we're talking late July or August there's a very good chance that 3.5 will be broken so we should at least revert but it'd be a shame to loose the HDMI stuff, I'd really expect that to be unrelated. It appears to be something to do with the jack detection that's going wrong. If I start the audio with the jack disconnected, I never get anything out of the board. It requires the jack to be connected before the first use. The on-board speakers used to work without the jack plugged in at one time but they seem to be completely non-functional now. Confused. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
On Mon, Jun 25, 2012 at 09:07:58AM +0300, Tomi Valkeinen wrote: On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the omapdss clocks. You used clk_prepare and clk_unprepare instead of clk_prepare_enable and clk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context. What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after clk_get, or prepare right before clk_enable? (And similarly for unprepare) I think you're looking at this the wrong way. Think of clk_prepare() as the _sleepable_ part of clk_enable(). So, think of clk_prepare() as ideally being placed just before clk_enable() with the exception that if that's not possible (because you're in a non-atomic context) it should be placed in a position as close to clk_enable() as possible which is atomic. Don't think of it as an extra step to be done after clk_get() but as an extra step needing to be done before clk_enable(). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] regulator: tps65217: Add device tree support
This commit adds device tree support for tps65217 pmic. And usage
details are added to device tree documentation.
Driver is tested by using kernel module with regulator set and get
APIs.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
These patches were tested along with these patches
* DT addition to AM33XX family
http://marc.info/?l=linux-omapm=134035826700991w=2
.../devicetree/bindings/regulator/tps65217.txt | 66 +++
drivers/mfd/tps65217.c | 67 +++-
drivers/regulator/tps65217-regulator.c |1 +
include/linux/mfd/tps65217.h |3 +-
4 files changed, 134 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
new file mode 100644
index 000..e84d26c
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -0,0 +1,66 @@
+TPS65217 family of regulators
+
+Required properties:
+- compatible: ti,tps65217
+- reg: I2C slave address
+- regulators: list of regulators provided by this controller, must be named
+ after their hardware counterparts: dcdc[1-3] and ldo[1-4]
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ tps: tps@24 {
+ compatible = ti,tps65217;
+
+ regulators {
+ dcdc1_reg: dcdc1 {
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2_reg: dcdc2 {
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3_reg: dcdc3 {
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt = 150;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index db194e4..61c097a 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -24,6 +24,7 @@
#include linux/slab.h
#include linux/regmap.h
#include linux/err.h
+#include linux/regulator/of_regulator.h
#include linux/mfd/core.h
#include linux/mfd/tps65217.h
@@ -132,6 +133,61 @@ int tps65217_clear_bits(struct tps65217 *tps, unsigned int
reg,
}
EXPORT_SYMBOL_GPL(tps65217_clear_bits);
+#ifdef CONFIG_OF
+static struct of_regulator_match reg_matches[] = {
+ { .name = dcdc1, .driver_data = (void *)TPS65217_DCDC_1 },
+ { .name = dcdc2, .driver_data = (void *)TPS65217_DCDC_2 },
+ { .name = dcdc3, .driver_data = (void *)TPS65217_DCDC_3 },
+ { .name = ldo1, .driver_data = (void *)TPS65217_LDO_1 },
+ { .name = ldo2, .driver_data = (void *)TPS65217_LDO_2 },
+ { .name = ldo3, .driver_data = (void *)TPS65217_LDO_3 },
+ { .name = ldo4, .driver_data = (void *)TPS65217_LDO_4 },
+};
+
+static struct tps65217_board *tps65217_parse_dt(struct i2c_client *client)
+{
+ struct device_node *node = client-dev.of_node;
+ struct tps65217_board *pdata;
+ struct device_node *regs;
+ int count = ARRAY_SIZE(reg_matches);
+ int ret, i;
+
+ regs = of_find_node_by_name(node,
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote: Currenlty HDMI fails to come up in the suspend-resume path. This patch helps that real-world scenario. What is the problem there? It'd be good to explain the problem in the patch description. Does the pm_runtime_get return -EACCES? On slightly different but related issue, currently OMAPDSS always spits lots of backtraces when it's compiled without CONFIG_PM_RUNTIME, because pm_runtime_put* always return -ENOSYS without CONFIG_PM_RUNTIME. So something like this patch proposes is needed, or maybe WARN_ON should check for -ENOSYS, I don't know.. -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP2+: AM33XX: Add tps65217 device tree data
Add device tree data for tps65217 regulator by adding all the consumers
necessary for AM335X-BeagleBone. The data will be map to a regulator
constraints which is required for regulator set_voltage and get_voltage
calls.
All tps65217 PMIC regulator constraints are placed in a seperate device
tree include file (tps65217.dtsi).
This patch also adds the I2C slave address of TPS65217 pmic to
am335x-bone.dts file.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
These patches were tested along with these patches
* DT addition to AM33XX family
http://marc.info/?l=linux-omapm=134035826700991w=2
arch/arm/boot/dts/am335x-bone.dts | 10 ++
arch/arm/boot/dts/tps65217.dtsi | 67 +
2 files changed, 77 insertions(+)
create mode 100644 arch/arm/boot/dts/tps65217.dtsi
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index a9af4db..a4d4415 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,3 +18,13 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+i2c1 {
+ clock-frequency = 40;
+
+ tps: tps@24 {
+ reg = 0x24;
+ };
+};
+
+/include/ tps65217.dtsi
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
new file mode 100644
index 000..5b9850b
--- /dev/null
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65217.pdf
+ */
+
+tps {
+ compatible = ti,tps65217;
+
+ regulators {
+ dcdc1_reg: dcdc1 {
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2_reg: dcdc2 {
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3_reg: dcdc3 {
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt = 150;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP2+: AM33XX: Add tps65910 device tree data
Add device tree data for tps65910 regulator by adding all the
consumers necessary for AM335X-EVM. The data will be map to a
regulator constraints which is required for regulator set_voltage
and get_voltage calls.
All tps65910 PMIC regulator constraints are placed in a seperate
device tree include file (tps65910.dtsi).
This patch also adds the I2C slave address of TPS65910 pmic to
am335x-evm.dts file.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
These patches were tested along with these patches
* DT addition to AM33XX family
http://marc.info/?l=linux-omapm=134035826700991w=2
arch/arm/boot/dts/am335x-evm.dts | 10 +
arch/arm/boot/dts/tps65910.dtsi | 76 ++
2 files changed, 86 insertions(+)
create mode 100644 arch/arm/boot/dts/tps65910.dtsi
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d6a97d9..15d03ba 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -18,3 +18,13 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+i2c1 {
+ clock-frequency = 40;
+
+ tps: tps@2D {
+ reg = 0x2D;
+ };
+};
+
+/include/ tps65910.dtsi
diff --git a/arch/arm/boot/dts/tps65910.dtsi b/arch/arm/boot/dts/tps65910.dtsi
new file mode 100644
index 000..c4f5d85
--- /dev/null
+++ b/arch/arm/boot/dts/tps65910.dtsi
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65910.pdf
+ */
+
+tps {
+ compatible = ti,tps65910;
+
+ regulators {
+ vrtc_reg: vrtc {
+ regulator-always-on;
+ };
+
+ vio_reg: vio {
+ regulator-always-on;
+ };
+
+ vdd1_reg: vdd1 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd2_reg: vdd2 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd3_reg: vdd3 {
+ regulator-always-on;
+ };
+
+ vdig1_reg: vdig1 {
+ regulator-always-on;
+ };
+
+ vdig2_reg: vdig2 {
+ regulator-always-on;
+ };
+
+ vpll_reg: vpll {
+ regulator-always-on;
+ };
+
+ vdac_reg: vdac {
+ regulator-always-on;
+ };
+
+ vaux1_reg: vaux1 {
+ regulator-always-on;
+ };
+
+ vaux2_reg: vaux2 {
+ regulator-always-on;
+ };
+
+ vaux33_reg: vaux33 {
+ regulator-always-on;
+ };
+
+ vmmc_reg: vmmc {
+ regulator-always-on;
+ };
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Add device tree support for AM33XX regulators
Add device tree support for regulators present on AM33XX family of devices like AM335X-EVM and AM335X-Bone. TPS65217 regulator is present on AM335X-Bone and TPS65910 on AM335X-EVM. First patch adds the device tree support to tps65217 regulator so that it will take the parameters from am335x-bone.dts file and convert to regulator parameters. Second patch adds tps65217 device tree data to am335x-bone.dts file with i2c salve address. Created seperate file tps65217, which contains the generic tps65217 device tree data. Third patch adds tps65910 device tree data to am335x-evm.dts file with i2c salve address. Created seperate file tps65910, which contains the generic tps65910 device tree data. These patches were tested along with these patches * DT addition to AM33XX family http://marc.info/?l=linux-omapm=134035826700991w=2 AnilKumar Ch (3): regulator: tps65217: Add device tree support ARM: OMAP2+: AM33XX: Add tps65217 device tree data ARM: OMAP2+: AM33XX: Add tps65910 device tree data .../devicetree/bindings/regulator/tps65217.txt | 66 + arch/arm/boot/dts/am335x-bone.dts | 10 +++ arch/arm/boot/dts/am335x-evm.dts | 10 +++ arch/arm/boot/dts/tps65217.dtsi| 67 + arch/arm/boot/dts/tps65910.dtsi| 76 drivers/mfd/tps65217.c | 67 - drivers/regulator/tps65217-regulator.c |1 + include/linux/mfd/tps65217.h |3 +- 8 files changed, 297 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt create mode 100644 arch/arm/boot/dts/tps65217.dtsi create mode 100644 arch/arm/boot/dts/tps65910.dtsi -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] regulator: tps65217: Add device tree support
On Mon, Jun 25, 2012 at 05:34:36PM +0530, AnilKumar Ch wrote: This commit adds device tree support for tps65217 pmic. And usage details are added to device tree documentation. Driver is tested by using kernel module with regulator set and get APIs. This needs to be updated for the patches Laxman recently posted for the regulator-compatible property (which are currently blocked on review from the ST Ericcsson guys but I'll probably apply them in the next couple of days if I don't hear back from them). signature.asc Description: Digital signature
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On 25 June 2012 15:00, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-25 at 14:19 +0530, Jassi Brar wrote: On 25 June 2012 11:50, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote: Currenlty HDMI fails to come up in the suspend-resume path. This patch helps that real-world scenario. What is the problem there? It'd be good to explain the problem in the patch description. Does the pm_runtime_get return -EACCES? Yes, it returns -EACCESS because RPM on devices is disabled during the period from suspend-start to resume-finished. So... You didn't answer my first comment, how can the code work? Sorry, don't know why I thought I didn't miss anything. The driver needs to enable the HW and the call to pm_runtime_get() is skipped. Won't this lead to crash as the DSS registers are accessed without the HW in enabled state? Hmm... how does the extant code in hdmi driver ensures DSS is up and running ? While it does sound important even to my limited knowledge of OMAPDSS, I see rpm of HDMI, VENC and RFBI only dependent on DISPC, not DSS. And for DISPC these drivers already hold a reference in their display enable/resume and keep it until disable/suspend. So we don't lose DISPC anytime it is really required. And what happens if the pm_runtime_get() call is skipped, but pm_runtime_put() is not? Not sure in what newly introduced scenario by this patch, because get/put both check for pm_enabled before proceeding. Am I overlooking something? thnx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] regulator: tps65217: Add device tree support
Hi Mark, Thanks for quick reply. On Mon, Jun 25, 2012 at 17:42:20, Mark Brown wrote: On Mon, Jun 25, 2012 at 05:34:36PM +0530, AnilKumar Ch wrote: This commit adds device tree support for tps65217 pmic. And usage details are added to device tree documentation. Driver is tested by using kernel module with regulator set and get APIs. This needs to be updated for the patches Laxman recently posted for the regulator-compatible property (which are currently blocked on review from the ST Ericcsson guys but I'll probably apply them in the next couple of days if I don't hear back from them). In that case, I will resubmit the patches once regulator-compatible property patches are pushed to linux-next. Thanks AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Mon, 2012-06-25 at 15:05 +0300, Grazvydas Ignotas wrote: On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote: Currenlty HDMI fails to come up in the suspend-resume path. This patch helps that real-world scenario. What is the problem there? It'd be good to explain the problem in the patch description. Does the pm_runtime_get return -EACCES? On slightly different but related issue, currently OMAPDSS always spits lots of backtraces when it's compiled without CONFIG_PM_RUNTIME, because pm_runtime_put* always return -ENOSYS without CONFIG_PM_RUNTIME. So something like this patch proposes is needed, or maybe WARN_ON should check for -ENOSYS, I don't know.. Hmm. I guess I'm missing some understanding about runtime PM. omapdss uses runtime PM to enable the underlying DSS hardware. If there's no runtime PM, how does the driver work? Or is it the job of hwmod/omap_device to keep all the hardware always enabled if runtime PM is not compiled in? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCHv10 1/7] I2C: OMAP: I2C register restore only if context is lost
Hi, On Mon, Jun 25, 2012 at 04:41:36PM +0530, Shubhrajyoti D wrote: Currently i2c register restore is done always. Adding conditional restore. The i2c register restore is done only if the context is lost or in case of error to be on the safe side. Cc: Kevin Hilman khil...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com how will this ever work with DT ? I say we get rid of the OMAP-specific API and build this context lost status directly on dev_pm_info and have something like pm_runtime_lost_context() or something with pm QoS tell you if a device has lost its context. Also, your commit log doesn't really state any problems you might have reached before, or any improvements wrt latency coming out of suspend and so on. IMHO, drivers need a generic way to differentiate if they're resuming from OFF or RET, otherwise we will end up with a bunch of OMAP-specific hackery on all drivers -- balbi signature.asc Description: Digital signature
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On 25 June 2012 17:35, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote: Currenlty HDMI fails to come up in the suspend-resume path. This patch helps that real-world scenario. What is the problem there? It'd be good to explain the problem in the patch description. Does the pm_runtime_get return -EACCES? On slightly different but related issue, currently OMAPDSS always spits lots of backtraces when it's compiled without CONFIG_PM_RUNTIME, because pm_runtime_put* always return -ENOSYS without CONFIG_PM_RUNTIME. So something like this patch proposes is needed, or maybe WARN_ON should check for -ENOSYS, I don't know.. I didn't check, but this patch should already fix that I think ? IMHO, for omapdss, we need not differentiate between -ENOSYS and -EACCESS because anyway the ultimate functions dispc_runtime_resume() and dispc_runtime_suspend() can't report failure (they always return 0). -j -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv10 4/7] I2C: OMAP: Do not initialise the completion everytime
Hi, On Mon, Jun 25, 2012 at 04:41:39PM +0530, Shubhrajyoti D wrote: Use INIT_COMPLETION instead of init_completion in transfer. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com --- drivers/i2c/busses/i2c-omap.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index c771c28..f1109f4 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -493,7 +493,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, w |= OMAP_I2C_BUF_RXFIF_CLR | OMAP_I2C_BUF_TXFIF_CLR; omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, w); - init_completion(dev-cmd_complete); + INIT_COMPLETION(dev-cmd_complete); dev-cmd_err = 0; w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT; @@ -1003,6 +1003,7 @@ omap_i2c_probe(struct platform_device *pdev) } platform_set_drvdata(pdev, dev); + init_completion(dev-cmd_complete); dev-reg_shift = (dev-flags OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) 3; -- 1.7.5.4 -- 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 -- balbi signature.asc Description: Digital signature
Re: [PATCHv10 5/7] I2C: OMAP: Remove the definition of SYSS_RESETDONE_MASK
Hi,
On Mon, Jun 25, 2012 at 04:41:40PM +0530, Shubhrajyoti D wrote:
Remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Also fixes the warning
CC drivers/i2c/busses/i2c-omap.o
drivers/i2c/busses/i2c-omap.c:163: warning: SYSS_RESETDONE_MASK redefined
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f1109f4..8344ad030 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -159,9 +159,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line
drive out */
#endif
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK (1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK (0x3 8)
#define SYSC_SIDLEMODE_MASK (0x3 3)
--
1.7.5.4
--
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv10 6/7] I2C: OMAP: Correct I2C revision for OMAP3
On Mon, Jun 25, 2012 at 04:41:41PM +0530, Shubhrajyoti D wrote:
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has the
same I2C revision as OMAP4. Correct the revision definition to reflect this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8344ad030..0557b0d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -50,8 +50,8 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
-#define OMAP_I2C_REV_ON_3430 0x3C
-#define OMAP_I2C_REV_ON_3530_44300x40
+#define OMAP_I2C_REV_ON_3430_35300x3C
+#define OMAP_I2C_REV_ON_3630_44300x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -305,7 +305,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
@@ -1021,7 +1021,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207)
dev-errata |= I2C_OMAP_ERRATA_I207;
- if (dev-rev = OMAP_I2C_REV_ON_3430)
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
dev-errata |= I2C_OMAP_ERRATA_I462;
if (!(dev-flags OMAP_I2C_FLAG_NO_FIFO)) {
@@ -1039,7 +1039,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-fifo_size = (dev-fifo_size / 2);
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
+ if (dev-rev = OMAP_I2C_REV_ON_3630_4430)
dev-b_hw = 0; /* Disable hardware fixes */
else
dev-b_hw = 1; /* Enable hardware fixes */
--
1.7.5.4
--
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Mon, 2012-06-25 at 17:57 +0530, Jassi Brar wrote: On 25 June 2012 15:00, Tomi Valkeinen tomi.valkei...@ti.com wrote: The driver needs to enable the HW and the call to pm_runtime_get() is skipped. Won't this lead to crash as the DSS registers are accessed without the HW in enabled state? Hmm... how does the extant code in hdmi driver ensures DSS is up and running ? While it does sound important even to my limited knowledge of OMAPDSS, I see rpm of HDMI, VENC and RFBI only dependent on DISPC, not DSS. DSS device is parent to all the DSS subdevices. So when a subdevice is enabled, DSS device is enabled first. But anyway, I wasn't referring to the DSS part of OMAPDSS, but to omapdss generally. If we do this: /* this is skipped, if runtime PM is disabled */ dispc_runtime_get(); /* this accesses a register, but the HW is disabled? */ dispc_read_reg(FOO); So again, I don't understand how the underlying HW gets enabled. Or does hwmod/omap_device code make sure that it's enabled while the board is being resumed? If so, what would happen if we continue the above scenario as follows: /* this is skipped, if runtime PM is disabled */ dispc_runtime_get(); /* this accesses a register, the HW is kept enabled by hwmod */ dispc_read_reg(FOO); /* at some time later the resume procedure ends, and hwmod doesn't keep the HW enabled any more */ /* this accesses a register, the HW is disabled */ dispc_read_reg(FOO); And for DISPC these drivers already hold a reference in their display enable/resume and keep it until disable/suspend. So we don't lose DISPC anytime it is really required. If all the displays are disabled, nobody keeps a reference to dispc. And what happens if the pm_runtime_get() call is skipped, but pm_runtime_put() is not? Not sure in what newly introduced scenario by this patch, because get/put both check for pm_enabled before proceeding. Am I overlooking something? Currently (for example) dispc_runtime_get/put call pm_runtime_get/put_sync. When somebody uses dispc_runtime_get, the same somebody knows it needs to call dispc_runtime_put later. Now, what happens if dispc_runtime_get is called when runtime PM is disabled (i.e. pm_runtime_get_sync is skipped), but runtime PM is enabled later when that somebody calls dispc_runtime_put (i.e. pm_runtime_put_sync is _not_ skipped)? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Monday 25 June 2012 06:00 PM, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 15:05 +0300, Grazvydas Ignotas wrote:
On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinentomi.valkei...@ti.com wrote:
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
Currenlty HDMI fails to come up in the suspend-resume path.
This patch helps that real-world scenario.
What is the problem there? It'd be good to explain the problem in the
patch description. Does the pm_runtime_get return -EACCES?
On slightly different but related issue, currently OMAPDSS always
spits lots of backtraces when it's compiled without CONFIG_PM_RUNTIME,
because pm_runtime_put* always return -ENOSYS without
CONFIG_PM_RUNTIME. So something like this patch proposes is needed, or
maybe WARN_ON should check for -ENOSYS, I don't know..
Hmm. I guess I'm missing some understanding about runtime PM. omapdss
uses runtime PM to enable the underlying DSS hardware. If there's no
runtime PM, how does the driver work? Or is it the job of
hwmod/omap_device to keep all the hardware always enabled if runtime PM
is not compiled in?
Yes, the below trick keeps all hwmods always enabled post the initial
setup if runtime PM is disabled.
from arch/arm/mach-omap2/io.c
static void __init omap_hwmod_init_postsetup(void)
{
u8 postsetup_state;
/* Set the default postsetup state for all hwmods */
#ifdef CONFIG_PM_RUNTIME
postsetup_state = _HWMOD_STATE_IDLE;
#else
postsetup_state = _HWMOD_STATE_ENABLED;
#endif
omap_hwmod_for_each(_set_hwmod_postsetup_state, postsetup_state);
omap_pm_if_early_init();
}
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Mon, 2012-06-25 at 18:12 +0530, Rajendra Nayak wrote:
On Monday 25 June 2012 06:00 PM, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 15:05 +0300, Grazvydas Ignotas wrote:
On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinentomi.valkei...@ti.com
wrote:
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
Currenlty HDMI fails to come up in the suspend-resume path.
This patch helps that real-world scenario.
What is the problem there? It'd be good to explain the problem in the
patch description. Does the pm_runtime_get return -EACCES?
On slightly different but related issue, currently OMAPDSS always
spits lots of backtraces when it's compiled without CONFIG_PM_RUNTIME,
because pm_runtime_put* always return -ENOSYS without
CONFIG_PM_RUNTIME. So something like this patch proposes is needed, or
maybe WARN_ON should check for -ENOSYS, I don't know..
Hmm. I guess I'm missing some understanding about runtime PM. omapdss
uses runtime PM to enable the underlying DSS hardware. If there's no
runtime PM, how does the driver work? Or is it the job of
hwmod/omap_device to keep all the hardware always enabled if runtime PM
is not compiled in?
Yes, the below trick keeps all hwmods always enabled post the initial
setup if runtime PM is disabled.
from arch/arm/mach-omap2/io.c
static void __init omap_hwmod_init_postsetup(void)
{
u8 postsetup_state;
/* Set the default postsetup state for all hwmods */
#ifdef CONFIG_PM_RUNTIME
postsetup_state = _HWMOD_STATE_IDLE;
#else
postsetup_state = _HWMOD_STATE_ENABLED;
#endif
omap_hwmod_for_each(_set_hwmod_postsetup_state, postsetup_state);
omap_pm_if_early_init();
}
Ah, ok, thanks.
Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
Are they supposed to handle the error values returned by runtime PM
functions somehow, or should they use #ifdef CONFIG_PM_RUNTIME?
Both options sound a bit difficult to me... With the first one it's
difficult to see if there was an actual error and we should somehow
react to it, or is everything fine and we just shouldn't care about
runtime PM. The second one requires ifdefs in many places.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
On Mon, 2012-06-25 at 17:18 +0530, Rajendra Nayak wrote: On Monday 25 June 2012 01:28 PM, Tomi Valkeinen wrote: On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote: On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote: Hi, On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote: In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the omapdss clocks. You used clk_prepare and clk_unprepare instead of clk_prepare_enable and clk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context. What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after clk_get, or prepare right before clk_enable? (And similarly for unprepare) clk_prepare/unprepare are useful for clocks which need the 'enable' logic to be implemented as a slow part (which can sleep) and a fast part (which does not sleep). For all the dss clocks in question we don't need a slow part and hence they do not have a .clk_prepare/unprepare platform hook. The framework however still does prepare usecounting (it has a prepare count and an enable count, and prepare count is expected to be non-zero while the clock is being enabled) and uses a mutex around to guard it. So while the dss driver would do multiple clk_enable/disable while its active, it seems fair to just prepare/unprepare the clocks once just after clk_get() and before clk_put() in this particular case. But the driver should not presume anything special about the clocks. In this case the dss driver would presume that the clocks it uses do not have prepare and unprepare hooks. If the generally proper way to use prepare/unprepare is in combination of enable/disable, then I think we should try to do that. makes sense. Lets see if any of the clk_enable/disable happen in atomic context, if not it would be just a matter of replacing all with a clk_prepare_enable/disable_unprepare. Else we might have to find a safe place sometime before clk_enable to prepare the clk and after clk_disable to unprepare it. I'll check if any of the dss clocks are enabled or disabled in atomic context. venc and hdmi use clk_enable/disable in runtime PM callbacks (suspend resume). If I understand correctly, the callbacks are not called in atomic context if pm_runtime_irq_safe() has not been used. And it is not used in omapdss. dsi uses clk_enable/disable in a different manner, but not in atomic context. So as far as I see, clocks are never handled in atomic context. Is everything related to the base clk stuff already in mainline? Can I take the clk_prepare/unprepare patch into my omapdss tree? A question about clk_prepare/unprepare, not directly related: let's say I have a driver for some HW block. The driver doesn't use clk functions, but uses runtime PM. The driver also sets pm_runtime_irq_safe(). Now, the driver can call pm_runtime_get_sync() in an atomic context, and this would lead to the underlying framework (hwmod, omap_device, I don't know who =) enabling the func clock for that HW. But this would happen in atomic context, so the underlying framework can't use clk_prepare. How does the underlying framework handle that case? (sorry if that's a stupid question =). Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On 25 June 2012 18:11, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-25 at 17:57 +0530, Jassi Brar wrote: On 25 June 2012 15:00, Tomi Valkeinen tomi.valkei...@ti.com wrote: The driver needs to enable the HW and the call to pm_runtime_get() is skipped. Won't this lead to crash as the DSS registers are accessed without the HW in enabled state? Hmm... how does the extant code in hdmi driver ensures DSS is up and running ? While it does sound important even to my limited knowledge of OMAPDSS, I see rpm of HDMI, VENC and RFBI only dependent on DISPC, not DSS. DSS device is parent to all the DSS subdevices. So when a subdevice is enabled, DSS device is enabled first. But anyway, I wasn't referring to the DSS part of OMAPDSS, but to omapdss generally. If we do this: /* this is skipped, if runtime PM is disabled */ dispc_runtime_get(); I hope you do realize that there is difference between PM is disabled on a device and the device is in some low-power state. pm_runtime_enabled() checks for the former. So under this light... /* this accesses a register, but the HW is disabled? */ dispc_read_reg(FOO); the H/W is already always enabled if CONFIG_PM_RUNTIME is not defined. If CONFIG_PM_RUNTIME is indeed defined, pm_runtime_enabled() will always return true after pm_runtime_enable() unless someone disables it explicitly - omapdss or the RPM stack(during suspend/resume). OMAPDSS never does so in the lifetime of a driver. So the only period in which pm_runtime_enabled() returns false, is when the platform is suspending, suspended or resuming. And what happens if the pm_runtime_get() call is skipped, but pm_runtime_put() is not? Not sure in what newly introduced scenario by this patch, because get/put both check for pm_enabled before proceeding. Am I overlooking something? Currently (for example) dispc_runtime_get/put call pm_runtime_get/put_sync. When somebody uses dispc_runtime_get, the same somebody knows it needs to call dispc_runtime_put later. Now, what happens if dispc_runtime_get is called when runtime PM is disabled (i.e. pm_runtime_get_sync is skipped), but runtime PM is enabled later when that somebody calls dispc_runtime_put (i.e. pm_runtime_put_sync is _not_ skipped)? As I said, for omapdss, PM is disabled (not device deactivated) only during rpm suspend/resume. And it should be no different than any lock protected section preempted by suspend-resume before reaching its end. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Mon, 2012-06-25 at 19:01 +0530, Jassi Brar wrote: On 25 June 2012 18:11, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-25 at 17:57 +0530, Jassi Brar wrote: On 25 June 2012 15:00, Tomi Valkeinen tomi.valkei...@ti.com wrote: The driver needs to enable the HW and the call to pm_runtime_get() is skipped. Won't this lead to crash as the DSS registers are accessed without the HW in enabled state? Hmm... how does the extant code in hdmi driver ensures DSS is up and running ? While it does sound important even to my limited knowledge of OMAPDSS, I see rpm of HDMI, VENC and RFBI only dependent on DISPC, not DSS. DSS device is parent to all the DSS subdevices. So when a subdevice is enabled, DSS device is enabled first. But anyway, I wasn't referring to the DSS part of OMAPDSS, but to omapdss generally. If we do this: /* this is skipped, if runtime PM is disabled */ dispc_runtime_get(); I hope you do realize that there is difference between PM is disabled on a device and the device is in some low-power state. pm_runtime_enabled() checks for the former. So under this light... /* this accesses a register, but the HW is disabled? */ dispc_read_reg(FOO); the H/W is already always enabled if CONFIG_PM_RUNTIME is not defined. If CONFIG_PM_RUNTIME is indeed defined, pm_runtime_enabled() will always return true after pm_runtime_enable() unless someone disables it explicitly - omapdss or the RPM stack(during suspend/resume). OMAPDSS never does so in the lifetime of a driver. So the only period in which pm_runtime_enabled() returns false, is when the platform is suspending, suspended or resuming. Right. So what happens in my example above? Normally if the driver does dispc_runtime_get() and dispc_read_reg(), the first call will enable the HW so the reg read works. But if the pm_runtime is disabled, say, during system suspend, with your patch dispc_runtime_get() will just return 0 without doing anything, and the dispc_read_reg() will crash because the HW is disabled (because nobody enabled it). Perhaps I'm missing something, but I don't quite understand how this works. And what happens if the pm_runtime_get() call is skipped, but pm_runtime_put() is not? Not sure in what newly introduced scenario by this patch, because get/put both check for pm_enabled before proceeding. Am I overlooking something? Currently (for example) dispc_runtime_get/put call pm_runtime_get/put_sync. When somebody uses dispc_runtime_get, the same somebody knows it needs to call dispc_runtime_put later. Now, what happens if dispc_runtime_get is called when runtime PM is disabled (i.e. pm_runtime_get_sync is skipped), but runtime PM is enabled later when that somebody calls dispc_runtime_put (i.e. pm_runtime_put_sync is _not_ skipped)? As I said, for omapdss, PM is disabled (not device deactivated) only during rpm suspend/resume. And it should be no different than any lock protected section preempted by suspend-resume before reaching its end. I'm not sure if I understand... If the driver does dispc_runtime_get() while the PM is disabled, say, during system resume, dispc_runtime_get() will do nothing and return 0. The driver thinks it succeeded, and will call dispc_runtime_put() later. Calling the dispc_runtime_put() could happen very soon, while runtime PM is still disabled, in which case everything works fine. But there's no rule to say dispc_runtime_put() has to be called very soon after dispc_runtime_get(). The driver might as well call put later, when runtime PM is enabled. This would end up with a pm_runtime_put call without a matching pm_runtime_get call. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 1/3] ARM: OMAP2+: nand: unify init functions
On 06/22/2012 04:00 AM, Afzal Mohammed wrote: Helper function for updating nand platform data has been added the capability to take timing structure arguement. Usage of omap_nand_flash_init() has been replaced by modifed one, omap_nand_flash_init was doing things similar to board_nand_init except that NAND CS# were being acquired based on bootloader setting. As CS# is hardwired for a given board, acquiring gpmc CS# has been removed, and updated with the value on board. NAND CS# used in beagle board was found to be CS0. Thomas Weber thomas.weber.li...@googlemail.com reported that value of devkit8000 to be CS0. Overo board was found to be using CS0 based on u-boot, while google grep says omap3touchbook too has CS0. Signed-off-by: Afzal Mohammed af...@ti.com Looks good. Reviewed-by: Jon Hunter jon-hun...@ti.com Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: HDQ: convert HDQ to runtime PM
* Paul Walmsley p...@pwsan.com [120622 07:16]: Hi Tony The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71: Linux 3.5-rc3 (2012-06-16 17:25:17 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-b-for-3.6 for you to fetch changes up to c354a86484b61e32100eb94c1f3f0aa512958cee: W1: OMAP HDQ1W: use runtime PM (2012-06-21 21:40:40 -0600) Convert the OMAP HDQ1W driver to use runtime PM. Make it available on all OMAP2+ chips that appear to have it integrated. Fix a problem preventing it from being used on OMAP4. Thanks pulling into devel-driver branch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: PRCM/hwmod: reimplement the OMAP PRCM I/O chain code for 3.6
* Paul Walmsley p...@pwsan.com [120622 08:41]: Hi Tony The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71: Linux 3.5-rc3 (2012-06-16 17:25:17 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-c-for-3.6 for you to fetch changes up to fafcdd53220f44d7ae2f06a9ce20c8d550df2d9b: ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle (2012-06-22 08:40:36 -0600) Reimplement the OMAP PRCM I/O chain code. Needed for I/O wakeups to work correctly. Thanks pulling into devel-pm branch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Afzal, Looks much better! On 06/22/2012 04:01 AM, Afzal Mohammed wrote: Reorganize gpmc-onenand initialization so that changes required for gpmc driver migration can be made smooth. Ensuring sync read/write are disabled in onenand cannot be expected to work properly unless GPMC is setup, this has been removed. Refactor set_async_mode set_sync_mode functions to separate out timing calculation actual configuration (GPMC OneNAND side). Thanks to Jon for his suggestions. Signed-off-by: Afzal Mohammed af...@ti.com --- v4: Reorganize set_sync/async functions in a better way v3: Refactor set_sync/async functions to separate out timing and configurations v2: Move ensuring that async mode in OneNAND has been setup from set_sync to setup function, improve commit message arch/arm/mach-omap2/gpmc-onenand.c | 153 +++- 1 file changed, 83 insertions(+), 70 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index 8863e0a..878182b 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -15,6 +15,7 @@ #include linux/platform_device.h #include linux/mtd/onenand_regs.h #include linux/io.h +#include linux/err.h #include asm/mach/flash.h @@ -25,6 +26,7 @@ #define ONENAND_IO_SIZE SZ_128K +static int hf, vhf, sync_read, sync_write, latency; I am wondering if we can remove hf, vhf, sync_read/write variables completely. We already have flags from sync_read/write and so we could just use the cfg-flags variable and remove sync_read/write variables. At the same time, we could create flags for ONENAND_FREQ_HF and ONENAND_FREQ_VHF or something like that. It could be nice to store the latency in onenand_data too. In other words, keep all the configuration in one place. Otherwise looks good. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] Add cyclic DMA support to OMAP DMA engine driver
Hi Russell, What is the status of the virtual dma and the series you have posted previously. Is it ready for merge? I would be away for 10days starting coming Thursday. So please let me know On Fri, 2012-06-22 at 09:59 +0100, Russell King - ARM Linux wrote: These three patches add support for returning the residue and cyclic DMA support to the OMAP DMA engine driver. As v3.5-rc is horribly broken on my OMAP platforms, I've had to back out all the sound/soc/omap changes from the last merge window to test this, inspite of Peter Ujfalusi maintaining that there is nothing wrong. I can't get working audio support on the OMAP4430SDP any other way. I am planning no further work on this until OMAP ASoC support gets fixed; due to Peter and my plans this summer, this is likely to be late July/ August time. This does not implement all of the weird and wonderfully different DMA setups which the OMAP ASoC driver appears to support (do we need soo much flexibility?) but it does support whatever is required for my OMAP4430SDP board. These patches apply on top of the previously posted series of DMA patches. I will be merging at least some of these down into the dmaengine: add OMAP DMA engine driver commit at some point. drivers/dma/omap-dma.c | 167 --- 1 files changed, 156 insertions(+), 11 deletions(-) ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
Hi Russell, On 06/22/2012 06:12 PM, Russell King - ARM Linux wrote: Before this goes much further... one fairly obvious and important point must be made. You're designing an API here. You're designing it *WITHOUT* involving the two most important people in its design that there are. The DMA engine maintainers. Is this how we go about designing APIs - behind maintainers backs and then presenting it to the maintainers as a fait accompli? Absolutely not, this was not the intent and your point is well understood. I have added Dan and Vinod, and will ensure that he is added in future. There's 86 messages in this thread, none of which have been copied to them in any way. Why aren't they involved? Initially this binding was not dma-engine centric. However, I should have included them in this version from the beginning as I had evolved it in that direction. Dan, Vinod, in this thread we have been discussing the addition of a generic device-tree binding for DMA controllers. In the below, we were discussing the addition of a device-tree API, which would work as a wrapper to the dma-engine dma_request_channel() API. I apologise for adding you late into the discussion. If you have any questions/comments let me know. Jon On Fri, Jun 22, 2012 at 05:52:08PM -0500, Jon Hunter wrote: Hi Arnd, On 06/14/2012 06:48 AM, Arnd Bergmann wrote: [snip] This would let us handle the following cases very easily: 1. one read-write channel dmas = dmac 0x3 match; 2. a choice of two read-write channels: dmas = dmacA 0x3 matchA, dmacB 0x3 matchB; 3. one read-channel, one write channel: dmas = dmac 0x1 match-read, dmac 0x2 match-write; 4. a choice of two read channels and one write channel: dmas = dmacA 0x1 match-readA, dmacA 0x2 match-write dmacB match-readB; And only the cases where we have more multiple channels that differ in more aspects would require named properties: 5. two different channels dmas = dmac 0x3 match-rwdata, dmac 0x1 match-status; dma-names = rwdata, status; 6. same as 5, but with a choice of channels: dmas = dmacA 0x3 match-rwdataA, dmacA 0x1 match-status; dmacB 0x3 match-rwdataB; dma-names = rwdata, status, rwdata; With a definition like that, we can implement a very simple device driver interface for the common cases, and a slightly more complex one for the more complex cases: 1. chan = of_dma_request_channel(dev-of_node, 0); 2. chan = of_dma_request_channel(dev-of_node, 0); 3. rxchan = of_dma_request_channel(dev-of_node, DMA_MEM_TO_DEV); txchan = of_dma_request_channel(dev-of_node, DMA_DEV_TO_MEM); 4. rxchan = of_dma_request_channel(dev-of_node, DMA_MEM_TO_DEV); txchan = of_dma_request_channel(dev-of_node, DMA_DEV_TO_MEM); 5. chan = of_dma_request_named_channel(dev-of_node, rwdata, 0); auxchan = of_dma_request_named_channel(dev-of_node, status, DMA_DEV_TO_MEM); 6. chan = of_dma_request_named_channel(dev-of_node, rwdata, 0); auxchan = of_dma_request_named_channel(dev-of_node, status, DMA_DEV_TO_MEM); In the above examples, did you imply that the of_dma_request_channel() function would return a type of struct dma_chan and so be calling dma_request_channel() underneath? I am been prototyping something, but wanted to make sure I am completely aligned on this :-) Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On 25 June 2012 19:19, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-06-25 at 19:01 +0530, Jassi Brar wrote: /* this accesses a register, but the HW is disabled? */ dispc_read_reg(FOO); the H/W is already always enabled if CONFIG_PM_RUNTIME is not defined. If CONFIG_PM_RUNTIME is indeed defined, pm_runtime_enabled() will always return true after pm_runtime_enable() unless someone disables it explicitly - omapdss or the RPM stack(during suspend/resume). OMAPDSS never does so in the lifetime of a driver. So the only period in which pm_runtime_enabled() returns false, is when the platform is suspending, suspended or resuming. Right. So what happens in my example above? Normally if the driver does dispc_runtime_get() and dispc_read_reg(), the first call will enable the HW so the reg read works. But if the pm_runtime is disabled, say, during system suspend, with your patch dispc_runtime_get() will just return 0 without doing anything, and the dispc_read_reg() will crash because the HW is disabled (because nobody enabled it). Hmm, I am not sure if new calls would/should be made to dispc.c after the system has suspended and before resumed. That is, anything other than from runtime_resume/suspend callbacks of DSS, DISPC, HDMI, VENC and RFBI, which rightly don't touch any dss reg but only enable/disable a clock. As we know, a subsystem should make sure any active work is cleared out before suspending and set some flag so that nothing runs until it has resumed. I don't say we can't crash the system with this patch, but then we would be violating rules of suspend-resume. As I said, for omapdss, PM is disabled (not device deactivated) only during rpm suspend/resume. And it should be no different than any lock protected section preempted by suspend-resume before reaching its end. I'm not sure if I understand... If the driver does dispc_runtime_get() while the PM is disabled, say, during system resume, dispc_runtime_get() will do nothing and return 0. The driver thinks it succeeded, and will call dispc_runtime_put() later. Calling the dispc_runtime_put() could happen very soon, while runtime PM is still disabled, in which case everything works fine. But there's no rule to say dispc_runtime_put() has to be called very soon after dispc_runtime_get(). The driver might as well call put later, when runtime PM is enabled. This would end up with a pm_runtime_put call without a matching pm_runtime_get call. Again, we need to see if there is really some situation where something new is attempted before the subsystem has resumed. If there is indeed, maybe omapdss need to flag it's suspended and prevent such thing until it has resumed. Btw, even without this patch, when dispc_runtime_get() does return error under rpm disabled, we disturb the dev.power.usage_count balance by not calling dispc_runtime_put() This patch doesn't make everything perfect, but only improve upon the current situation. thnx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crash with VMALLOC api
Hi David, On Mon, Jun 25, 2012 at 2:17 AM, David Rientjes rient...@google.com wrote: On Sat, 23 Jun 2012, R, Sricharan wrote: Hi, I am observing a below crash with VMALLOC call on mainline kernel. The issue happens when there is insufficent vmalloc space. Isn't it expected that the API should return a NULL instead of crashing when there is not enough memory?. Yes. This can be reproduced with succesive vmalloc calls for a size of about say 10MB, without a vfree, thus exhausting the memory. Strangely when vmalloc is requested for a large chunk, then at that time API does not crash instead returns a NULL correctly. Please correct me if my understanding is not correct.. -- [ 345.059841] Unable to handle kernel paging request at virtual address 90011000 [ 345.067063] pgd = ebc34000 [ 345.069793] [90011000] *pgd= [ 345.073383] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 345.078685] Modules linked in: bcmdhd cfg80211 inv_mpu_ak8975 inv_mpu_kxtf9 mpu3050 [ 345.086380] CPU: 0 Tainted: G W (3.4.0-rc1-05660-g0d4b175 #1) [ 345.093351] PC is at vmap_page_range_noflush+0xf0/0x200 [ 345.098569] LR is at vmap_page_range+0x14/0x50 [ 345.103005] pc : [c01091c8] lr : [c01092ec] psr: 8013 [ 345.103009] sp : ebc41e38 ip : fe000fff fp : 2000 [ 345.114472] r10: c0a78480 r9 : 90011000 r8 : c096e2ac [ 345.119685] r7 : 90011000 r6 : r5 : fe00 r4 : [ 345.126198] r3 : 50011452 r2 : f385c400 r1 : fe000fff r0 : f385c400 [ 345.132713] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 345.139835] Control: 10c5387d Table: abc3404a DAC: 0015 Couple requests: - since you're already running an -rc kernel, would it be possible to try 3.5-rc4, which was released today, instead? - could you disassemble vmap_page_range_noflush and post the output or map the offset back to the line in the code? Thanks a lot for the response. Debugged this further and the real issue was because of static mapping for a 1MB io page and the vmalloc mapping for a 1MB dram page falling in to one PGD entry (PGDIR_SHIFT is 0x21). While trying to setup the pagetables for the dram page, the PGD entry of static io map is used, resulting in the paging fault. This was because of a recent change that brought the static io mappings under the vmalloc space. Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] ARM: OMAP4470: Fix OMAP4470 boot failure
OMAP4470 currently fails to boot, printing various messages such as ...
omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
omap_hwmod: mpu: cannot _init_clocks
[ cut here ]
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
omap_hwmod: mpu: couldn't init clocks
Modules linked in:
[c001c7fc] (unwind_backtrace+0x0/0xf4) from [c0043c64]
(warn_slowpath_common+0x4c/0x64)
[c0043c64] (warn_slowpath_common+0x4c/0x64) from [c0043d10]
(warn_slowpath_fmt+0x30/0x40)
[c0043d10] (warn_slowpath_fmt+0x30/0x40) from [c0674208] (_init+0x2a0/0x2e4)
[c0674208] (_init+0x2a0/0x2e4) from [c067428c]
(omap_hwmod_setup_one+0x40/0x60)
[c067428c] (omap_hwmod_setup_one+0x40/0x60) from [c0674280]
(omap_hwmod_setup_one+0x34/0x60)
[c0674280] (omap_hwmod_setup_one+0x34/0x60) from [c06726f4]
(omap_dm_timer_init_one+0x30/0x250)
[c06726f4] (omap_dm_timer_init_one+0x30/0x250) from [c0672930]
(omap2_gp_clockevent_init+0x1c/0x108)
[c0672930] (omap2_gp_clockevent_init+0x1c/0x108) from [c0672c60]
(omap4_timer_init+0x10/0x5c)
[c0672c60] (omap4_timer_init+0x10/0x5c) from [c066c418]
(time_init+0x20/0x30)
[c066c418] (time_init+0x20/0x30) from [c0668814] (start_kernel+0x1b0/0x304)
[c0668814] (start_kernel+0x1b0/0x304) from [80008044] (0x80008044)
---[ end trace 1b75b31a2719ed1c ]---
The problem is that currently none of the clocks are being registered for
OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.
This fix allows the kernel to boot without failure using a simple RAMDISK file
system on OMAP4470 blaze board.
V2:
- Per feedback from Paul and Benoit the 4470 clock data is incomplete for new
modules such as the 2D graphics block that has been added to the 4470.
Therefore add a warning to indicate that the clock data is incomplete.
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index b825049..de53b70 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3407,9 +3407,12 @@ int __init omap4xxx_clk_init(void)
if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
cpu_clkflg = CK_443X;
- } else if (cpu_is_omap446x()) {
+ } else if (cpu_is_omap446x() || cpu_is_omap447x()) {
cpu_mask = RATE_IN_4460 | RATE_IN_4430;
cpu_clkflg = CK_446X | CK_443X;
+
+ if (cpu_is_omap447x())
+ pr_warn(WARNING: OMAP4470 clock data incomplete!\n);
} else {
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Mon, 2012-06-25 at 11:51 -0500, Jon Hunter wrote: Hi Russell, On 06/22/2012 06:12 PM, Russell King - ARM Linux wrote: Before this goes much further... one fairly obvious and important point must be made. You're designing an API here. You're designing it *WITHOUT* involving the two most important people in its design that there are. The DMA engine maintainers. Is this how we go about designing APIs - behind maintainers backs and then presenting it to the maintainers as a fait accompli? Absolutely not, this was not the intent and your point is well understood. I have added Dan and Vinod, and will ensure that he is added in future. There's 86 messages in this thread, none of which have been copied to them in any way. Why aren't they involved? Initially this binding was not dma-engine centric. However, I should have included them in this version from the beginning as I had evolved it in that direction. Dan, Vinod, in this thread we have been discussing the addition of a generic device-tree binding for DMA controllers. In the below, we were discussing the addition of a device-tree API, which would work as a wrapper to the dma-engine dma_request_channel() API. I apologise for adding you late into the discussion. If you have any questions/comments let me know. Looks like this a long discussion, I will try to go through archives. But am still unsure about about dmaengine part. If we have DT binding for dma controllers, why it they worry about dma_request_channel() IMO, the problem of channel mapping is not DT specific, it need to be solved at dmaengine and possibly the required mapping can come from DT among other mechanisms for various platforms. This is what google told me about this patch set: Design of DMA helpers 1. Supporting devices with multiple DMA controllers In the case of DMA controllers that are using DMA Engine, requesting a channel is performed by calling the following function. struct dma_chan *dma_request_channel(dma_cap_mask_t mask, dma_filter_fn filter_fn, void *filter_param); The mask variable is used to identify the device controller in a list of controllers. The filter_fn and filter_param are used to identify the required dma channel and return a handle to the dma channel of type dma_chan. From the examples I have seen, the mask and filter_fn are constant for a given DMA controller. Therefore, when registering a DMA controller with device tree we can pass these parameters and store them so that a device can request them when requesting a channel. Hence, based upon this our register function for the DMA controller now looks like this. int of_dma_controller_register(struct device_node *np, dma_cap_mask_t *mask, dma_filter_fn fn); IMO we should do away with filer functions. If we solve the mapping problem, then we don't need a filer. 2. Supporting legacy devices not using DMA Engine These devices present a problem, as there may not be a uniform way to easily support them with regard to device tree. However, _IF_ legacy devices that are not using DMA Engine, only have a single DMA controller, then this problem is a lot simpler. For example, if we look at the previously proposed API for registering a DMA controller (where we pass the mask and function pointer to the DMA Engine filter function) we can simply pass NULL and hence, a driver requesting the DMA channel information would receive NULL for the DMA Engine specific parameters. Then for legacy devices we simply need a means to return the channel information (more on this later). If there are legacy devices that do have multiple DMA controllers, then maybe they need to be converted to support DMA Engine. I am not sure if this is unreasonable??? Why should these be supported? They should be converted to use dmaengine over a reasonable amount of time. 3. Representing and requesting channel information From a hardware perspective, a DMA channel could be represented as ... i. channel index/number ii. channel transfer type (optional) iii. DMA interrupt mapping (optional) Please note that the transfer type is used to indicate if the transfer is to device from memory, to memory from device, to memory from memory, etc. This can be useful when there is a device such as an MMC device that uses two DMA channels, one for reading (RX) and one for writing (TX). From a dma controller perspective, it can service both with single channel. I have dma controller which can talk to three peripherals on both transmit and receive direction. The point is that 1:1 mapping of dma channel does not exist. So any representation which tries to do this may not work. Forgetting device tree for now, some drivers use strings to represent a DMA channel instead of using an integer. I
Re: [PATCH V2] ARM: OMAP4470: Fix OMAP4470 boot failure
Adding linux-arm ML.
Jon
On 06/25/2012 12:38 PM, Jon Hunter wrote:
OMAP4470 currently fails to boot, printing various messages such as ...
omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
omap_hwmod: mpu: cannot _init_clocks
[ cut here ]
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
omap_hwmod: mpu: couldn't init clocks
Modules linked in:
[c001c7fc] (unwind_backtrace+0x0/0xf4) from [c0043c64]
(warn_slowpath_common+0x4c/0x64)
[c0043c64] (warn_slowpath_common+0x4c/0x64) from [c0043d10]
(warn_slowpath_fmt+0x30/0x40)
[c0043d10] (warn_slowpath_fmt+0x30/0x40) from [c0674208]
(_init+0x2a0/0x2e4)
[c0674208] (_init+0x2a0/0x2e4) from [c067428c]
(omap_hwmod_setup_one+0x40/0x60)
[c067428c] (omap_hwmod_setup_one+0x40/0x60) from [c0674280]
(omap_hwmod_setup_one+0x34/0x60)
[c0674280] (omap_hwmod_setup_one+0x34/0x60) from [c06726f4]
(omap_dm_timer_init_one+0x30/0x250)
[c06726f4] (omap_dm_timer_init_one+0x30/0x250) from [c0672930]
(omap2_gp_clockevent_init+0x1c/0x108)
[c0672930] (omap2_gp_clockevent_init+0x1c/0x108) from [c0672c60]
(omap4_timer_init+0x10/0x5c)
[c0672c60] (omap4_timer_init+0x10/0x5c) from [c066c418]
(time_init+0x20/0x30)
[c066c418] (time_init+0x20/0x30) from [c0668814]
(start_kernel+0x1b0/0x304)
[c0668814] (start_kernel+0x1b0/0x304) from [80008044] (0x80008044)
---[ end trace 1b75b31a2719ed1c ]---
The problem is that currently none of the clocks are being registered for
OMAP4470 devices and so on boot-up no clocks can be found and the kernel
panics.
This fix allows the kernel to boot without failure using a simple RAMDISK file
system on OMAP4470 blaze board.
V2:
- Per feedback from Paul and Benoit the 4470 clock data is incomplete for new
modules such as the 2D graphics block that has been added to the 4470.
Therefore add a warning to indicate that the clock data is incomplete.
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index b825049..de53b70 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3407,9 +3407,12 @@ int __init omap4xxx_clk_init(void)
if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
cpu_clkflg = CK_443X;
- } else if (cpu_is_omap446x()) {
+ } else if (cpu_is_omap446x() || cpu_is_omap447x()) {
cpu_mask = RATE_IN_4460 | RATE_IN_4430;
cpu_clkflg = CK_446X | CK_443X;
+
+ if (cpu_is_omap447x())
+ pr_warn(WARNING: OMAP4470 clock data incomplete!\n);
} else {
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current state of AM33xx patches
On 21.06.2012 15:50, Daniel Mack wrote: On 18.06.2012 10:15, Hiremath, Vaibhav wrote: On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote: From: Daniel Mack zon...@gmail.com Hey, can anybody give me a quick wrap-up about the current state of AM33xx based SoCs in mainline? What are the next steps to get things merged? There is a wiki page [1] that is intended to provide a summary, but I'm confident it is not up-to-date. Page updated now... http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x_Linux_Status Great, thanks. So if things get upstreamed, which is the repo/branch they appear in? In other words: where is the code people should write patches against? I couldn't find an answer to that yet. ping? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] memory: emif: add device tree support to emif driver
On Tue, Jun 19, 2012 at 02:33:11PM +0530, Shilimkar, Santosh wrote:
@@ -1644,11 +1923,23 @@ static void __attribute__((unused))
freq_post_notify_handling(void)
spin_unlock_irqrestore(emif_lock, irq_state);
}
+#if defined(CONFIG_OF)
+static const struct of_device_id emif_of_match[] = {
+ { .compatible = ti,emif-4d },
+ { .compatible = ti,emif-4d5 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, emif_of_match);
+#endif
+
static struct platform_driver emif_driver = {
.remove = __exit_p(emif_remove),
.shutdown = emif_shutdown,
.driver = {
.name = emif,
+#if defined(CONFIG_OF)
+ .of_match_table = of_match_ptr(emif_of_match),
+#endif
Are these two still #if defined needed?
Also, what about the IS_DEFINED macro?
And, if you resend, please resend the whole series, I don't have the old
ones around anymore.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Monday 25 June 2012, Vinod Koul wrote: On Mon, 2012-06-25 at 11:51 -0500, Jon Hunter wrote: Hi Russell, Dan, Vinod, in this thread we have been discussing the addition of a generic device-tree binding for DMA controllers. In the below, we were discussing the addition of a device-tree API, which would work as a wrapper to the dma-engine dma_request_channel() API. I apologise for adding you late into the discussion. If you have any questions/comments let me know. Looks like this a long discussion, I will try to go through archives. But am still unsure about about dmaengine part. If we have DT binding for dma controllers, why it they worry about dma_request_channel() IMO, the problem of channel mapping is not DT specific, it need to be solved at dmaengine and possibly the required mapping can come from DT among other mechanisms for various platforms. This is what google told me about this patch set: dma_request_channel is called with some information about the channel provided in its arguments, and the driver might get that from a number of places. In the case of having a fully populated device tree with this binding, the driver calling (of_)dma_request_channel does not need to know about any of that information because we should be able to encapsulate that completely in device tree data. It does not replace the regular interface but wraps around it to provide a higher abstraction level where possible. Of course if you think we should not be doing that but instead have of_dma_request_channel() live besides dma_request_channel() rather than calling it, that should be absolutely fine too. In the case of DMA controllers that are using DMA Engine, requesting a channel is performed by calling the following function. struct dma_chan *dma_request_channel(dma_cap_mask_t mask, dma_filter_fn filter_fn, void *filter_param); The mask variable is used to identify the device controller in a list of controllers. The filter_fn and filter_param are used to identify the required dma channel and return a handle to the dma channel of type dma_chan. From the examples I have seen, the mask and filter_fn are constant for a given DMA controller. Therefore, when registering a DMA controller with device tree we can pass these parameters and store them so that a device can request them when requesting a channel. Hence, based upon this our register function for the DMA controller now looks like this. int of_dma_controller_register(struct device_node *np, dma_cap_mask_t *mask, dma_filter_fn fn); IMO we should do away with filter functions. If we solve the mapping problem, then we don't need a filer. The channel data in the device tree is still in a format that is specific to that dmaengine driver and interpreted by it. Using the regular dma_filter_fn prototype is not necessary, but it would be convenient because the dmaengine code already knows how to deal with it. If we don't use this method, how about adding another callback to struct dma_device like bool (*device_match)(struct dma_chan *chan, struct property *req); 2. Supporting legacy devices not using DMA Engine These devices present a problem, as there may not be a uniform way to easily support them with regard to device tree. However, _IF_ legacy devices that are not using DMA Engine, only have a single DMA controller, then this problem is a lot simpler. For example, if we look at the previously proposed API for registering a DMA controller (where we pass the mask and function pointer to the DMA Engine filter function) we can simply pass NULL and hence, a driver requesting the DMA channel information would receive NULL for the DMA Engine specific parameters. Then for legacy devices we simply need a means to return the channel information (more on this later). If there are legacy devices that do have multiple DMA controllers, then maybe they need to be converted to support DMA Engine. I am not sure if this is unreasonable??? Why should these be supported? They should be converted to use dmaengine over a reasonable amount of time. I agree, at least for the long run. However, that is a separate issue to work on. Right now we need a generic way to represent dma requests independent of how they are used in the kernel. The device tree binding is supposed to be operating system independent so there should be nothing in it that requires the use of the linux dmaengine code. For drivers that do not use dmaengine, we have to make a decision whether it's worth adding support for the DT binding first and converting the driver and its users to dmaengine later, or whether it's better to use the dmaengine API right away to avoid having to do changes twice. 3. Representing and requesting channel information From a
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 18:12 +0530, Rajendra Nayak wrote:
On Monday 25 June 2012 06:00 PM, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 15:05 +0300, Grazvydas Ignotas wrote:
On Mon, Jun 25, 2012 at 9:20 AM, Tomi Valkeinentomi.valkei...@ti.com wrote:
On Sat, 2012-06-23 at 13:36 +0530, jaswinder.si...@linaro.org wrote:
Currenlty HDMI fails to come up in the suspend-resume path.
This patch helps that real-world scenario.
What is the problem there? It'd be good to explain the problem in the
patch description. Does the pm_runtime_get return -EACCES?
On slightly different but related issue, currently OMAPDSS always
spits lots of backtraces when it's compiled without CONFIG_PM_RUNTIME,
because pm_runtime_put* always return -ENOSYS without
CONFIG_PM_RUNTIME. So something like this patch proposes is needed, or
maybe WARN_ON should check for -ENOSYS, I don't know..
Hmm. I guess I'm missing some understanding about runtime PM. omapdss
uses runtime PM to enable the underlying DSS hardware. If there's no
runtime PM, how does the driver work? Or is it the job of
hwmod/omap_device to keep all the hardware always enabled if runtime PM
is not compiled in?
Yes, the below trick keeps all hwmods always enabled post the initial
setup if runtime PM is disabled.
from arch/arm/mach-omap2/io.c
static void __init omap_hwmod_init_postsetup(void)
{
u8 postsetup_state;
/* Set the default postsetup state for all hwmods */
#ifdef CONFIG_PM_RUNTIME
postsetup_state = _HWMOD_STATE_IDLE;
#else
postsetup_state = _HWMOD_STATE_ENABLED;
#endif
omap_hwmod_for_each(_set_hwmod_postsetup_state,postsetup_state);
omap_pm_if_early_init();
}
Ah, ok, thanks.
Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
Are they supposed to handle the error values returned by runtime PM
functions somehow, or should they use #ifdef CONFIG_PM_RUNTIME?
hmm, I always though with CONFIG_RUNTIME_PM=n, the functions would
be stubbed to return success and not failure. And the _pm_runtime_resume
function indeed seems to return 1, which is not failure but just saying
that your device is already active/enabled.
The _pm_runtime_suspend and _pm_runtime_idle do return a -ENOSYS, which
is something only returned when CONFIG_RUNTIME_PM=n, so if you really
want to handle failing pm_runtime_put_sync cases, maybe you still can.
But then, I don't know if there is anything you can do to recover from
a failing pm_runtime_put_sync, except for warning the user maybe.
Both options sound a bit difficult to me... With the first one it's
difficult to see if there was an actual error and we should somehow
react to it, or is everything fine and we just shouldn't care about
runtime PM. The second one requires ifdefs in many places.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
On Monday 25 June 2012 06:44 PM, Tomi Valkeinen wrote: venc and hdmi use clk_enable/disable in runtime PM callbacks (suspend resume). If I understand correctly, the callbacks are not called in atomic context if pm_runtime_irq_safe() has not been used. And it is not used in omapdss. dsi uses clk_enable/disable in a different manner, but not in atomic context. So as far as I see, clocks are never handled in atomic context. Is everything related to the base clk stuff already in mainline? Can I take the clk_prepare/unprepare patch into my omapdss tree? Well the Common Clk framework is already in mainline, but we still don;t have CONFIG_COMMON_CLK enabled for our builds yet. So until we do so, clk_prepare/unprepare will just be stubs which do nothing. I will repost the patch getting rid of the clk_prepare/unprepare and adding clk_prepare_enable/disable_unprepare instead. A question about clk_prepare/unprepare, not directly related: let's say I have a driver for some HW block. The driver doesn't use clk functions, but uses runtime PM. The driver also sets pm_runtime_irq_safe(). Now, the driver can call pm_runtime_get_sync() in an atomic context, and this would lead to the underlying framework (hwmod, omap_device, I don't know who =) enabling the func clock for that HW. But this would happen in atomic context, so the underlying framework can't use clk_prepare. How does the underlying framework handle that case? (sorry if that's a stupid question =). No, its not a stupid question at all. I have been thinking about this too to figure out whats the best way to handle this. For now, the patches I posted, do an early clk_prepare (like I did for dss) for all hwmod clocks as I have no way to know which ones will have their _enable, _idle etc called in atomic context. Maybe I should see if there is a way I can do so only for those devices which end up calling a pm_runtime_irq_safe() and not do it early for all. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] memory: emif: add device tree support to emif driver
On Mon, Jun 25, 2012 at 11:58 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Jun 19, 2012 at 02:33:11PM +0530, Shilimkar, Santosh wrote:
@@ -1644,11 +1923,23 @@ static void __attribute__((unused))
freq_post_notify_handling(void)
spin_unlock_irqrestore(emif_lock, irq_state);
}
+#if defined(CONFIG_OF)
+static const struct of_device_id emif_of_match[] = {
+ { .compatible = ti,emif-4d },
+ { .compatible = ti,emif-4d5 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, emif_of_match);
+#endif
+
static struct platform_driver emif_driver = {
.remove = __exit_p(emif_remove),
.shutdown = emif_shutdown,
.driver = {
.name = emif,
+#if defined(CONFIG_OF)
+ .of_match_table = of_match_ptr(emif_of_match),
+#endif
Are these two still #if defined needed?
Also, what about the IS_DEFINED macro?
Yes. To avoid the build break in !DT build.
And, if you resend, please resend the whole series, I don't have the old
ones around anymore.
Ok. Will repost the entire series.
As mentioned earlier, the series needs to go via OMAP tree beasue the
other three
patches are touching the platform files. I will need your ack on the
$subject patch
to queue that via Tony's linux-omap tree.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] memory: emif: add device tree support to emif driver
On Tuesday 26 June 2012 10:39 AM, Shilimkar, Santosh wrote:
+#if defined(CONFIG_OF)
+static const struct of_device_id emif_of_match[] = {
+ { .compatible = ti,emif-4d },
+ { .compatible = ti,emif-4d5 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, emif_of_match);
+#endif
+
static struct platform_driver emif_driver = {
.remove = __exit_p(emif_remove),
.shutdown = emif_shutdown,
.driver = {
.name = emif,
+#if defined(CONFIG_OF)
+ .of_match_table = of_match_ptr(emif_of_match),
+#endif
Are these two still #if defined needed?
Also, what about the IS_DEFINED macro?
Yes. To avoid the build break in !DT build.
No, infact of_match_ptr is there just so you can avoid a
#ifdef around and not break !CONFIG_OF.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] memory: emif: add device tree support to emif driver
On Tue, Jun 26, 2012 at 10:49 AM, Rajendra Nayak rna...@ti.com wrote:
On Tuesday 26 June 2012 10:39 AM, Shilimkar, Santosh wrote:
+#if defined(CONFIG_OF)
+static const struct of_device_id emif_of_match[] = {
+ { .compatible = ti,emif-4d },
+ { .compatible = ti,emif-4d5 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, emif_of_match);
+#endif
+
static struct platform_driver emif_driver = {
.remove = __exit_p(emif_remove),
.shutdown = emif_shutdown,
.driver = {
.name = emif,
+#if defined(CONFIG_OF)
+ .of_match_table = of_match_ptr(emif_of_match),
+#endif
Are these two still #if defined needed?
Also, what about the IS_DEFINED macro?
Yes. To avoid the build break in !DT build.
No, infact of_match_ptr is there just so you can avoid a
#ifdef around and not break !CONFIG_OF.
Need to recheck but the build was throwing error becasue of emif_of_match
mostly.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] memory: emif: add device tree support to emif driver
On Tuesday 26 June 2012 10:53 AM, Shilimkar, Santosh wrote:
On Tue, Jun 26, 2012 at 10:49 AM, Rajendra Nayakrna...@ti.com wrote:
On Tuesday 26 June 2012 10:39 AM, Shilimkar, Santosh wrote:
+#if defined(CONFIG_OF)
+static const struct of_device_id emif_of_match[] = {
+ { .compatible = ti,emif-4d },
+ { .compatible = ti,emif-4d5 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, emif_of_match);
+#endif
+
static struct platform_driver emif_driver = {
.remove = __exit_p(emif_remove),
.shutdown = emif_shutdown,
.driver = {
.name = emif,
+#if defined(CONFIG_OF)
+ .of_match_table = of_match_ptr(emif_of_match),
+#endif
Are these two still #if defined needed?
Also, what about the IS_DEFINED macro?
Yes. To avoid the build break in !DT build.
No, infact of_match_ptr is there just so you can avoid a
#ifdef around and not break !CONFIG_OF.
Need to recheck but the build was throwing error becasue of emif_of_match
mostly.
You still need the first one. I meant the second one around
'of_match_ptr' should be removed.
With !CONFIG_OF, of_match_ptr(_ptr) is just defined as NULL.
Regards
Santosh
--
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
