Re: [PATCH v2 0/4] OMAP4: CPUidle: Add coupled idle support
Hi Santosh, Santosh Shilimkar writes: > Kevin, > > Now Colin's v3 [1] is apearing in Len Brown's next branch, I have rebased > OMAP4 support against it. I need to pick up couple of fixes [2] posted on > top of v3 [1] version and arm-soc 'omap/cpuidle-cleanup' branch lined up > for 3.5. Great. > This series adds the coupled cpuidle support for OMAP4 and also removes > the hard dependency of off-lining CPU1 to trigger deeper CPU C-states. > It has been build tested for all OMAP builds and functionally tested > on OMAP4430 SDP. > > I have put together a branch with: > 1) Len Brown's 'next' > : git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux > 2) ARM-SOC 'omap/cpuidle-cleanup' > : git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > 3) Two couple_idle_fixes picked up from [2] > > And same is available: > > git://gitorious.org/omap-sw-develoment/linux-omap-dev.git > for_3.5/omap4_couple_idle Excellent, thanks for pulling this together with the dependencies. Linus has now merged the arm-soc/pm branch containing the OMAP CPUidle cleanup from Daniel. Also, I just ping'd Len on the status of Colin's fixes. As soon as all the depenencies are queued/merged I'll rebase this on the right mainline commit and get this queued up for v3.6. Thanks for keeping on top of this, 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: [PATCHv9 00/10] I2C fixes
+Neil Brown
Shubhrajyoti D writes:
> The patch series does the following
>
> - Warn fixes if CONFIG_PM_RUNTIME is not selected.
> - In case of i2c remove register access was done without any
> get_sync fix the same.
> - Folds a patch from Tasslehoff to prevent any merge conflicts.
> - Prevents the XDUF flag to be set if the underflow condition is not met.
> - As per discussion in [1] .Adds a patch to rename the 1p153 errata and
> use the unique id instead as the section number in the recent errata
> docs has changed.
>
Shubhrajyoti,
Can you add one more patch to this series.
The patch below from Neil Brown has been circulating for awhile, and
I've been using it locally for awhile now too. It would help if it got
into this series and got some broader testing.
Thanks,
Kevin
>From 0c6effd8356e6273c294490a576551ef37ae6799 Mon Sep 17 00:00:00 2001
From: NeilBrown
Date: Fri, 30 Dec 2011 12:40:30 +1100
Subject: [PATCH] OMAP/I2C - Fix timeout problem during suspend.
On a board with OMAP3 processor and TWL4030 Power management,
we need to talk to the TWL4030 during late suspend but cannot
because the I2C interrupt is disabled (as late suspend disables
interrupt).
e.g. I get messages like:
[ 62.161102] musb-omap2430 musb-omap2430: LATE power domain suspend
[ 63.167205] omap_i2c omap_i2c.1: controller timed out
[ 63.183044] twl: i2c_read failed to transfer all messages
[ 64.182861] omap_i2c omap_i2c.1: controller timed out
[ 64.198455] twl: i2c_write failed to transfer all messages
[ 65.198455] omap_i2c omap_i2c.1: controller timed out
[ 65.203765] twl: i2c_write failed to transfer all messages
The stack shows omap2430_runtime_suspend calling twl4030_set_suspend
which tries to power-down the USB PHY (twl4030_phy_suspend ->
twl4030_phy_power -> __twl4030_phy_power which as a nice WARN_ON
that helps).
Then we get the same in resume:
[ 69.603912] musb-omap2430 musb-omap2430: EARLY power domain resume
[ 70.610473] omap_i2c omap_i2c.1: controller timed out
[ 70.626129] twl: i2c_write failed to transfer all messages
etc.
So don't disable interrupts for I2C.
Acked-by: Kevin Hilman
Tested-by: Kevin Hilman
Signed-off-by: NeilBrown
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..e024c50 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1092,7 +1092,7 @@ omap_i2c_probe(struct platform_device *pdev)
isr = (dev->rev < OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
omap_i2c_isr;
- r = request_irq(dev->irq, isr, 0, pdev->name, dev);
+ r = request_irq(dev->irq, isr, IRQF_NO_SUSPEND, pdev->name, dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
--
1.7.9.2
--
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] MAINTAINERS: add OMAP CPUfreq driver to OMAP Power Management section
Add the OMAP CPUFreq driver to the list of files in the OMAP Power Management section. I've already been maintaining this driver, this just makes it official. Signed-off-by: Kevin Hilman --- MAINTAINERS |1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index b362709..60ff5d4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4791,6 +4791,7 @@ M:Kevin Hilman L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/*omap*/*pm* +F: drivers/cpufreq/omap-cpufreq.c OMAP POWERDOMAIN/CLOCKDOMAIN SOC ADAPTATION LAYER SUPPORT M: Rajendra Nayak -- 1.7.9.2 -- 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 00/10] I2C fixes
Shubhrajyoti D writes: > The patch series does the following > > - Warn fixes if CONFIG_PM_RUNTIME is not selected. > - In case of i2c remove register access was done without any > get_sync fix the same. > - Folds a patch from Tasslehoff to prevent any merge conflicts. > - Prevents the XDUF flag to be set if the underflow condition is not met. > - As per discussion in [1] .Adds a patch to rename the 1p153 errata and > use the unique id instead as the section number in the recent errata > docs has changed. > > v9: > Fix the comments from Wolfram Sang > > [1] http://www.spinics.net/lists/linux-i2c/msg07607.html > > Tested on omap4sdp and omap3sdp. Can you also describe how it was tested? With the runtime PM changes, does it still hit full-chip retention in idle and suspend after these changes? I had a few minor comments on this version, otherwise feel free add Reviewed-by: Kevin Hilman That being said, before this is merged, I woudl like to see some more non-author Tested-bys. We've been having lots of regressions of late from OMAP drivers that are not being sufficiently tested before merging. We need to ensure proper testing before merge. Other testers should also report what platforms they tested on, and how it was tested. Thanks, 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: [PATCHv9 09/10] I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached
Shubhrajyoti D writes:
> Currently in the 1.153 errata handling while waiting for transmitter
> underflow if NACK is got the XUDF(Transmit underflow) flag is also set.
-EOVERFLOW
This sentence needs a rewrite and some punctuation. It does not read well.
> The flag is set after wait for the condition is over.
>
> Cc: Alexander Shishkin
> Acked-by: Moiz Sonasath
> Signed-off-by: Shubhrajyoti D
> ---
> drivers/i2c/busses/i2c-omap.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 43b0efb..c0aa16b 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -730,7 +730,6 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev,
> u16 *stat, int *err)
> if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
> omap_i2c_ack_stat(dev, *stat & (OMAP_I2C_STAT_XRDY |
> OMAP_I2C_STAT_XDR));
> - *err |= OMAP_I2C_STAT_XUDF;
> return -ETIMEDOUT;
> }
>
> @@ -743,6 +742,7 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev,
> u16 *stat, int *err)
> return 0;
> }
>
> + *err |= OMAP_I2C_STAT_XUDF;
> return 0;
> }
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: [PATCHv9 07/10] I2C: OMAP: Handle error check for pm runtime
Shubhrajyoti D writes: > If PM runtime get_sync fails return with the error > so that no further reads/writes goes through the interface. > This will avoid possible abort. Add a error message in case > of failure with the cause of the failure. > > Signed-off-by: Shubhrajyoti D > --- > drivers/i2c/busses/i2c-omap.c | 14 +++--- > 1 files changed, 11 insertions(+), 3 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 44e8cfa..a72874e 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -585,7 +585,9 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg > msgs[], int num) > int i; > int r; > > - pm_runtime_get_sync(dev->dev); > + r = pm_runtime_get_sync(dev->dev); > + if (r < 0) > + return r; nit: please use IS_ERR_VALUE() 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: [PATCHv9 02/10] I2C: OMAP: Fix the mismatch of pm_runtime enable and disable
Shubhrajyoti D writes: > Currently the i2c driver calls the pm_runtime_enable and never > the disable. This may cause a warning when pm_runtime_enable > checks for the count match.Attempting to fix the same by calling > pm_runtime_disable in the error and the remove path. Looks right. Can you be more specific in the changelog about when the errors/warning happens? e.g. why pm_runtime_enable() is called again? Is this on module unload/reload? Other than that Acked-by: Kevin Hilman > Cc: Kevin Hilman > Cc: Rajendra Nayak > Signed-off-by: Shubhrajyoti D > --- > drivers/i2c/busses/i2c-omap.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 4f4188d..c851672 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1090,6 +1090,7 @@ 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); > @@ -1110,6 +,7 @@ omap_i2c_remove(struct platform_device *pdev) > free_irq(dev->irq, dev); > i2c_del_adapter(&dev->adapter); > omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); > + pm_runtime_disable(&pdev->dev); > iounmap(dev->base); > kfree(dev); > mem = platform_get_resource(pdev, IORESOURCE_MEM, 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
[PATCH] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3. This blocks device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active. This in turn prevents the WKUP
clockdomain from transitioning to idle. There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.
It turns out that there is no need to take the 32k sync timer out of
idle. The IP block itself probably does not have any native idle
handling at all, due to its simplicity. Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active. So
we can safely leave the 32k sync timer in target-no-idle mode, even
while we continue to access it.
This workaround is implemented by defining a new hwmod flag,
HWMOD_ALWAYS_FORCE_SIDLE, that places the IP block into target
force-idle mode even when enabled. The 32k sync timer hwmods are
marked with this flag for OMAP3 and OMAP4 SoCs. (On OMAP2xxx, no OCP
header existed on the 32k sync timer.)
Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses. These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource. But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.
Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI. But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.
This patch is effectively a workaround for a hardware oversight. A
better hardware approach would have been to implement a smart-idle
target idle mode for this IP block. The smart-idle mode in this case
would behave identically to the force-idle mode. We consider the
force-idle and no-idle target idle mode settings to be intended for
debugging and automatic idle management bug workarounds only.
This patch is a collaboration between Kevin Hilman
and Paul Walmsley .
References:
1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
(SWPU223U), available from:
http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
(SWPU223U)
3. ibid.
Cc: Tony Lindgren
Cc: Vaibhav Hiremath
Cc: Benoît Cousson
Tested-by: Kevin Hilman
Signed-off-by: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 17 +++--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |9 +
4 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bf86f7e..096474c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1124,10 +1124,12 @@ static struct omap_hwmod_addr_space * __init
_find_mpu_rt_addr_space(struct omap
* _enable_sysc - try to bring a module out of idle via OCP_SYSCONFIG
* @oh: struct omap_hwmod *
*
- * If module is marked as SWSUP_SIDLE, force the module out of slave
- * idle; otherwise, configure it for smart-idle. If module is marked
- * as SWSUP_MSUSPEND, force the module out of master standby;
- * otherwise, configure it for smart-standby. No return value.
+ * Ensure that the OCP_SYSCONFIG register for the IP block represented
+ * by @oh is set to indicate to the PRCM that the IP block is active.
+ * Usually this means placing the module into smart-idle mode and
+ * smart-standby, but if there is a bug in the automatic idle handling
+ * for the IP block, it may need to be placed into the force-idle or
+ * no-idle variants of these modes. No return value.
*/
static void _enable_sysc(struct omap_hwmod *oh)
{
@@ -1141,8 +1143,11 @@ static void _enable_sysc(struct omap_hwmod *oh)
sf = oh->class->sysc->sysc_flags;
if (sf & SYSC_HAS_SIDLEMODE) {
- idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
- HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ if (oh->flags & HWMOD_ALWAYS_FORCE_SIDLE)
+ idlemode = HWMOD_IDLEMODE_FORCE;
+ else
+ idlemode = (oh->flags & HWMOD_
Re: [PATCHv9 06/10] I2C: OMAP: Fix the crash in i2c remove
Hi Wolfram, Wolfram Sang writes: > On Wed, May 02, 2012 at 08:02:11PM +0530, Shubhrajyoti D wrote: >> In omap_i2c_remove we are accessing the I2C_CON register without >> enabling the clocks. Fix the same by enabling the clocks and disabling >> it. [...] > I'd really like a comment from the PM experts if each and every driver > has to ensure that the clocks are enabled on remove like this? Yes, this is correct. In fact, this is the goal of runtime PM. The driver itself tells the PM core (using runtime PM) when the device needs to be accessible and when it doesn't. Technically speaking, the it's up to the platform-specific runtime PM implementation to decide whether or not the clocks are actually disable or not (e.g. due to wakeup latency requirements, it might decide not to cut clocks.) Because of that, the changelog should be reworded to say something like "ensure device is accessible" instead of "enable the clocks", because the runtime PM implementation does more than just manage clocks. Kevin P.S. It's great to see you helping out maintaining i2c drivers. Thanks! P.P.S. Before you merge this, I would strongly recommend we wait for a few more Tested-bys, and a bit more description about how this was tested. We've been having quite a few problems with regressions introduced in OMAP drivers that have not been well reviewed or tested. -- 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 PATCH 09/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor
Hi.
On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
> In the System Control Module, OMAP supplies a voltage reference
> and a temperature sensor feature that are gathered in the band
> gap voltage and temperature sensor (VBGAPTS) module. The band
> gap provides current and voltage reference for its internal
> circuits and other analog IP blocks. The analog-to-digital
> converter (ADC) produces an output value that is proportional
> to the silicon temperature.
>
> This patch provides a platform driver which expose this feature.
> It is moduled as a MFD child of the System Control Module core
> MFD driver.
>
> This driver provides only APIs to access the device properties,
> like temperature, thresholds and update rate.
>
> Signed-off-by: Eduardo Valentin
> Signed-off-by: Keerthy
> ---
> .../devicetree/bindings/thermal/omap_bandgap.txt | 27 +
> drivers/thermal/Kconfig| 13 +
> drivers/thermal/Makefile |4 +-
> drivers/thermal/omap-bandgap.c | 1601
>
> drivers/thermal/omap-bandgap.h | 63 +
> 5 files changed, 1707 insertions(+), 1 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/thermal/omap_bandgap.txt
> create mode 100644 drivers/thermal/omap-bandgap.c
> create mode 100644 drivers/thermal/omap-bandgap.h
>
>
Add private spin lock in omap-bandgap driver to prevent blocking of
control module general registers access.
I wasn't able to test - I have panda 4430 board.
TODO:
Prevent over-usage of spin_lock/spin_unlock for sequential calls of
bg_writel().
Signed-off-by: Konstantin Baydarov
Index: omap-thermal/drivers/mfd/omap-control-core.c
===
--- omap-thermal.orig/drivers/mfd/omap-control-core.c
+++ omap-thermal/drivers/mfd/omap-control-core.c
@@ -67,6 +67,19 @@ EXPORT_SYMBOL_GPL(omap_control_readl);
int omap_control_writel(struct device *dev, u32 val, u32 reg)
{
struct omap_control *omap_control = dev_get_drvdata(dev);
+
+ if (!omap_control)
+ return -EINVAL;
+
+ writel(val, omap_control->base + reg);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_writel);
+
+int omap_control_lock_writel(struct device *dev, u32 val, u32 reg)
+{
+ struct omap_control *omap_control = dev_get_drvdata(dev);
unsigned long flags;
if (!omap_control)
@@ -78,7 +91,7 @@ int omap_control_writel(struct device *d
return 0;
}
-EXPORT_SYMBOL_GPL(omap_control_writel);
+EXPORT_SYMBOL_GPL(omap_control_lock_writel);
/**
* omap_control_get: returns the control module device pinter
@@ -136,6 +149,9 @@ static int __devinit omap_control_probe(
struct device_node *np = dev->of_node;
struct omap_control *omap_control;
+ printk("\n\t\t omap_control_probe(): enter ");
+ dump_stack();
+
omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
if (!omap_control) {
dev_err(dev, "not enough memory for omap_control\n");
Index: omap-thermal/drivers/thermal/omap-bandgap.c
===
--- omap-thermal.orig/drivers/thermal/omap-bandgap.c
+++ omap-thermal/drivers/thermal/omap-bandgap.c
@@ -154,6 +154,7 @@ struct temp_sensor_registers {
u32 status_cold_mask;
u32 bgap_efuse;
+ spinlock_t bg_reg_lock;
};
/**
@@ -579,6 +580,17 @@ omap5430_adc_to_temp[OMAP5430_ADC_END_VA
124600, 124900, 125000, 125000, 125000, 125000,
};
+static int bg_writel(struct device *dev, u32 val, u32 reg, spinlock_t *lock)
+{
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(lock, flags);
+ ret = omap_control_writel(dev, val, reg);
+ spin_unlock_irqrestore(lock, flags);
+ return ret;
+}
+
static irqreturn_t talert_irq_handler(int irq, void *data)
{
struct omap_bandgap *bg_ptr = data;
@@ -615,7 +627,7 @@ static irqreturn_t talert_irq_handler(in
ctrl |= tsr->mask_hot_mask;
}
- r |= omap_control_writel(cdev, ctrl, tsr->bgap_mask_ctrl);
+ r |= bg_writel(cdev, ctrl, tsr->bgap_mask_ctrl,
&tsr->bg_reg_lock);
if (r) {
dev_err(bg_ptr->dev, "failed to ack talert
interrupt\n");
@@ -705,7 +717,7 @@ static int temp_sensor_unmask_interrupts
reg_val |= tsr->mask_cold_mask;
else
reg_val &= ~tsr->mask_cold_mask;
- err |= omap_control_writel(cdev, reg_val, tsr->bgap_mask_ctrl);
+ err |= bg_writel(cdev, reg_val, tsr->bgap_mask_ctrl, &tsr->bg_reg_lock);
if (err) {
dev_err(bg_ptr->dev, "failed to unmask interrupts\n");
@@ -751,14 +763,14 @@ int temp_sensor_configure_thot(struct om
/* write the new t_cold value */
reg_val = thresh_val & (~tsr->threshold_tcold_
Ftrace Timer on OMAP3
Hi everyone,
we're having some trouble getting useful results from Ftrace on OMAP3
(Gumstix Overo). As you can see in the example output below, function
duration can't be displayed with a precision higher than about 30.5 us,
which matches the frequency of the 32 kHz platform timer. For OMAP1,
using OMAP_MPU_TIMER instead of CONFIG_OMAP_32K_TIMER should provide
better results [1], but I couldn't find anything similar for OMAP3. Just
setting CONFIG_OMAP_32K_TIMER=N didn't change the results. Did I miss
anything, or isn't there any more precise timer?
Best regards,
Thomas Klute
[1]
http://elinux.org/images/0/0c/Bird-LS-2009-Measuring-function-duration-with-ftrace.pdf
Example Ftrace output:
876.252136 | 0) | sys_sendmsg() {
876.252166 | 0) |rom_rtadd() {
876.252197 | 0) 0.000 us| release_queue_for_dst();
876.252197 | 0) 0.000 us| add_route();
876.252197 | 0) + 30.517 us |}
876.252258 | 0) + 91.553 us | }
--
876.311859 | 0) | sys_sendmsg() {
876.311889 | 0) |rom_rtadd() {
876.311889 | 0) + 30.518 us | release_queue_for_dst();
876.311920 | 0) 0.000 us| add_route();
876.311920 | 0) + 30.518 us |}
876.311950 | 0) + 91.552 us | }
--
876.371704 | 0) | sys_sendmsg() {
876.371765 | 0) |rom_rtadd() {
876.371765 | 0) 0.000 us| release_queue_for_dst();
876.371765 | 0) 0.000 us| add_route();
876.371795 | 0) + 30.517 us |}
876.371826 | 0) ! 122.071 us | }
--
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 PATCH 08/11] ARM: OMAP4+: Adding the temperature sensor register set bit fields
On 5/25/2012 10:25 AM, Eduardo Valentin wrote: OMAP4460 specific temperature sensor register bit fields are added. Existing OMAP4 entries are renamed to OMAP4430. Signed-off-by: Keerthy Signed-off-by: Eduardo Valentin --- arch/arm/mach-omap2/include/mach/control.h | 116 Now that we do have a dedicated driver for the bandgap, I guess it will be better to put these defines inside the driver directly. Benoit 1 files changed, 116 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/control.h b/arch/arm/mach-omap2/include/mach/control.h index cf42764..171b504 100644 --- a/arch/arm/mach-omap2/include/mach/control.h +++ b/arch/arm/mach-omap2/include/mach/control.h @@ -230,6 +230,122 @@ /* OMAP44xx control McBSP padconf */ #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP0x061c +/* TEMP_SENSOR OMAP4430 */ +#define OMAP4430_BGAP_TEMPSOFF_SHIFT 12 +#define OMAP4430_BGAP_TEMPSOFF_MASK(1<< 12) +#define OMAP4430_BGAP_TSHUT_SHIFT 11 +#define OMAP4430_BGAP_TSHUT_MASK (1<< 11) +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_MASK(1<< 10) +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_SHIFT9 +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK (1<< 9) +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK(1<< 8) +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff<< 0) + +/* TEMP_SENSOR OMAP4460 */ +#define OMAP4460_BGAP_TEMPSOFF_SHIFT 13 +#define OMAP4460_BGAP_TEMPSOFF_MASK(1<< 13) +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_SHIFT11 +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK (1<< 11) +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK(1<< 10) +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff<< 0) + +/* BANDGAP_CTRL */ +#define OMAP4460_SINGLE_MODE_SHIFT 31 +#define OMAP4460_SINGLE_MODE_MASK (1<< 31) +#define OMAP4460_MASK_HOT_SHIFT1 +#define OMAP4460_MASK_HOT_MASK (1<< 1) +#define OMAP4460_MASK_COLD_SHIFT 0 +#define OMAP4460_MASK_COLD_MASK(1<< 0) + +/* BANDGAP_COUNTER */ +#define OMAP4460_COUNTER_SHIFT 0 +#define OMAP4460_COUNTER_MASK (0xff<< 0) + +/* BANDGAP_THRESHOLD */ +#define OMAP4460_T_HOT_SHIFT 16 +#define OMAP4460_T_HOT_MASK(0x3ff<< 16) +#define OMAP4460_T_COLD_SHIFT 0 +#define OMAP4460_T_COLD_MASK (0x3ff<< 0) + +/* TSHUT_THRESHOLD */ +#define OMAP4460_TSHUT_HOT_SHIFT 16 +#define OMAP4460_TSHUT_HOT_MASK(0x3ff<< 16) +#define OMAP4460_TSHUT_COLD_SHIFT 0 +#define OMAP4460_TSHUT_COLD_MASK (0x3ff<< 0) + +/* BANDGAP_STATUS */ +#define OMAP4460_CLEAN_STOP_SHIFT 3 +#define OMAP4460_CLEAN_STOP_MASK (1<< 3) +#define OMAP4460_BGAP_ALERT_SHIFT 2 +#define OMAP4460_BGAP_ALERT_MASK (1<< 2) +#define OMAP4460_HOT_FLAG_SHIFT1 +#define OMAP4460_HOT_FLAG_MASK (1<< 1) +#define OMAP4460_COLD_FLAG_SHIFT 0 +#define OMAP4460_COLD_FLAG_MASK(1<< 0) + +/* TEMP_SENSOR OMAP5430 */ +#define OMAP5430_BGAP_TEMP_SENSOR_SOC_SHIFT12 +#define OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK (1<< 12) +#define OMAP5430_BGAP_TEMPSOFF_SHIFT 11 +#define OMAP5430_BGAP_TEMPSOFF_MASK(1<< 11) +#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK(1<< 10) +#define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff<< 0) + +/* BANDGAP_CTRL */ +#define OMAP5430_MASK_HOT_CORE_SHIFT 5 +#define OMAP5430_MASK_HOT_CORE_MASK(1<< 5) +#define OMAP5430_MASK_COLD_CORE_SHIFT 4 +#define OMAP5430_MASK_COLD_CORE_MASK (1<< 4) +#define OMAP5430_MASK_HOT_MM_SHIFT 3 +#define OMAP5430_MASK_HOT_MM_MASK (1<< 3) +#define OMAP5430_MASK_COLD_MM_SHIFT2 +#define OMAP5430_MASK_COLD_MM_MASK (1<< 2) +#define OMAP5430_MASK_HOT_MPU_SHIFT1 +#define OMAP5430_MA
Re: [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
On 5/25/2012 10:25 AM, Eduardo Valentin wrote:
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
(p.s. the mailbox for musb in omap4 is present in system control
module)
[kis...@ti.com: wrote the original API's related to USB functions]
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
...
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @dev: struct device *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), the phy should call this API
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), the phy should call
+ * this API to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * The phy should call this API, if OMAP is disconnected from host or device.
+ */
+int omap4_usb_phy_mailbox(struct device *dev, u32 val)
+{
+ return omap_control_writel(dev, val, CONTROL_USBOTGHS_CONTROL);
Mmm, I'm missing something. The device for usb_phy mailbox cannot be the
same than the device for the scm...
+}
+EXPORT_SYMBOL_GPL(omap4_usb_phy_mailbox);
+
+static int __devinit omap_usb_phy_probe(struct platform_device *pdev)
+{
+ struct omap_control *omap_control;
+
+ omap_control = dev_get_drvdata(pdev->dev.parent);
Directly accessing your parent device data does not looks very nice to me.
Maybe that's only me, but I'll never try to sneak into my parents stuff :-)
You previously exposed an API to get/put the control module device, so I
guess you should use it from the probe.
+
+ if (!omap_control) {
+ dev_err(&pdev->dev, "no omap_control in our parent\n");
+ return -EINVAL;
+ }
BTW, where is the omap_control struct used?
I'm not sure to understand how the user is supposed to call that API?
Regards,
Benoit
--
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 PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
Hi Edurardo,
A few doubts,
On Fri, May 25, 2012 at 1:55 PM, Eduardo Valentin
wrote:
> Created a new platform driver for the platform device created by the
> control module mfd core, wrt usb. This driver has API's to power on/off
> the phy and the API's to write to musb mailbox.
>
> (p.s. the mailbox for musb in omap4 is present in system control
> module)
>
> [kis...@ti.com: wrote the original API's related to USB functions]
> Signed-off-by: Kishon Vijay Abraham I
> Signed-off-by: Eduardo Valentin
> ---
> drivers/usb/otg/Kconfig | 13
> drivers/usb/otg/Makefile | 1 +
> drivers/usb/otg/omap4-usb-phy.c | 130
> +
> include/linux/usb/omap4_usb_phy.h | 53 +++
> 4 files changed, 197 insertions(+), 0 deletions(-)
> create mode 100644 drivers/usb/otg/omap4-usb-phy.c
> create mode 100644 include/linux/usb/omap4_usb_phy.h
>
> diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
> index 5c87db0..e2840f1 100644
> --- a/drivers/usb/otg/Kconfig
> +++ b/drivers/usb/otg/Kconfig
> @@ -78,6 +78,19 @@ config TWL6030_USB
> are hooked to this driver through platform_data structure.
> The definition of internal PHY APIs are in the mach-omap2 layer.
>
> +config OMAP4_USB_PHY
> + tristate "Texas Instruments OMAP4+ USB pin control driver"
> + depends on MFD_OMAP_CONTROL
> + help
> + If you say yes here you get support for the Texas Instruments
> + OMAP4+ USB pin control driver. The register set is part of system
> + control module.
> +
> + USB phy in OMAP configures control module register for powering on
> + the phy, configuring VBUSVALID, AVALID, IDDIG and SESSEND. For
> + performing the above mentioned configuration, API's are added in
> + by this children of the control module driver.
> +
> config NOP_USB_XCEIV
> tristate "NOP USB Transceiver Driver"
> select USB_OTG_UTILS
> diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
> index 41aa509..60c8c83 100644
> --- a/drivers/usb/otg/Makefile
> +++ b/drivers/usb/otg/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
> obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
> obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
> obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
> +obj-$(CONFIG_OMAP4_USB_PHY) += omap4-usb-phy.o
> obj-$(CONFIG_NOP_USB_XCEIV) += nop-usb-xceiv.o
> obj-$(CONFIG_USB_ULPI) += ulpi.o
> obj-$(CONFIG_USB_ULPI_VIEWPORT) += ulpi_viewport.o
> diff --git a/drivers/usb/otg/omap4-usb-phy.c b/drivers/usb/otg/omap4-usb-phy.c
> new file mode 100644
> index 000..a29ea45
> --- /dev/null
> +++ b/drivers/usb/otg/omap4-usb-phy.c
> @@ -0,0 +1,130 @@
> +/*
> + * OMAP4 system control module driver, USB control children
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * Contact:
> + * Kishon Vijay Abraham I
> + * Eduardo Valentin
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * omap4_usb_phy_power - power on/off the phy using control module reg
> + * @dev: struct device *
> + * @on: 0 or 1, based on powering on or off the PHY
Could it be bool ?
> + *
> + * omap_usb2 can call this API to power on or off the PHY.
> + */
> +int omap4_usb_phy_power(struct device *dev, int on)
> +{
> + u32 val;
> + int ret;
> +
> + if (on) {
> + ret = omap_control_readl(dev, CONTROL_DEV_CONF, &val);
> + if (!ret && (val & PHY_PD)) {
> + ret = omap_control_writel(dev, ~PHY_PD,
> + CONTROL_DEV_CONF);
> + /* XXX: add proper documentation for this delay */
> + mdelay(200);
Also does it have to be a busy one?
--
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: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
Hi Tomi, Paul! On Fri, May 25, 2012 at 10:24 AM, Tomi Valkeinen wrote: > On Thu, 2012-05-24 at 18:39 -0600, Paul Walmsley wrote: >> cc Jean >> >> Hello Tomi, >> >> On Wed, 16 May 2012, Tomi Valkeinen wrote: >> >> > I also suspect that this could be just a plain DSS bug. The default FIFO >> > low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the >> > FIFO when there are 960 or less bytes in the fifo, and stops at 1023. >> > The fifo is 1024 bytes). The values are calculated with fifo_size - >> > burst_size and fifo_size - 1. >> > >> > We are now using FIFO merge features, which combines multiple fifos into >> > one when possible, making the fifo size 1024*3 = 3072. Using the same >> > low threshold and increasing the high threshold to 960/3071 works fine. >> > Changing the high threshold to 3008 causes underflows. Increasing the >> > low threshold to ~1600 makes DSS work again. >> >> Just a few thoughts. >> >> In terms of the high threshold, it seems really strange to me that >> changing the high threshold would make such a difference. Naïvely, I'd >> assume that you'd want to set it as high as possible? I suppose in cases >> where the interconnect is congested, setting it lower might allow lower >> latency for other interconnect users, but I'd hope we don't have to worry >> much about that. So it doesn't seem to me that there would be any >> advantage to setting it lower than the maximum. > > It's true that the high threshold should be set as high as possible, and > this is what we do. Except for DSI command mode output on OMAP3, where, > for unknown reason, the highest value (fifosize - 1) doesn't work and we > need to program it to fifosize - burstsize. And this was causing the > original problem, fifosize - burstsize was not working for other outputs > properly. > > I guess this also hints that there's something wrong with omap3 and the > dss fifo thresholds. > >> Probably the low threshold is the more important parameter, from a PM >> perspective. If you know the FIFO's drain rate and the low threshold, it >> should be possible to calculate the maximum latency that the FIFO can >> tolerate to avoid an underflow. This could be used to specify a device PM >> QoS constraint to prevent the interconnect latency from exceeding that >> value. > > Yes, this is how the low threshold should be adjusted. I have never > tried to calculate the threshold need, though, as I haven't had all the > information and understanding to properly calculate it. > >> I'd guess the calculations would be something like this -- (I hope you can >> correct my relative ignorance of the DSS in the following estimates): >> >> Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO >> drain rate would be 864 x 480 x 32 bits/second. Since the FIFO width is >> 32 bits, that's > > I think the DSS fifo entries are 8 bit on omap2/3, 128bits on omap4. At > least those are the "units" used with fifo size, threshold sizes, burst > size, etc. > >> 864 x 480 = 414 780 FIFO entries/second, or >> >> (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry. >> >> So if you need a low FIFO threshold at 960 entries, you could call the >> device PM QoS functions to set a wakeup latency constraint for the >> interconnect would be nothing greater than this: >> >> (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs >> >> (The reality is that it would need to be something less than this, to >> account for the time needed for the GFX DMA transfer to start supplying >> data, etc.) > > Makes sense. > > Another reason for underflows we have is the different rotation engines. > VRFB on omap2/3, and TILER on omap4. Both increase the "work" needed to > get pixels, although I'm not sure what the actual causes for the > increased work are. > >> The ultimate goal, with Jean's device PM QoS patches, is that these >> constraints could change the DPLL autoidle settings or powerdomain states >> to ensure the constraint was met. He's got a page here: Indeed! The core code is ready and the OMAP power domains code is under review for the moment. The ultimate goal is to split the overall latency of a device into the contributors (SW, HW SoC, HW external etc.), so the DPLL relock time would be taken into account. However without the submitted code in place there is no way to build the feature in incremental steps. >> >> http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement In the wiki page there is a link to the ELC/Fosdem presentation [1] about the new model for the latency. [1] http://omappedia.org/wiki/File:ELC-2012-jpihet-DeviceLatencyModel.pdf >> >> (Unfortunately it's not clear what the DPLL autoidle modes and voltage >> scaling bits are set to for many of the estimates, and we also know that The code is from an l-o tree + the measurement code in, so the DPLL are allowed to auto-idle. In the new model the DPLL relock latency contribution should be split from the power domains latency. >> t
Re: [RFC PATCH 06/11] OMAP2+: use control module mfd driver in omap_type
Hi Eduardo,
On 5/25/2012 10:25 AM, Eduardo Valentin wrote:
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/id.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5bb9746..acfd698 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
@@ -40,8 +41,14 @@ EXPORT_SYMBOL(omap_rev);
int omap_type(void)
{
+ struct device *scm;
+ int ret = 0;
u32 val = 0;
+ scm = omap_control_get();
+ if (IS_ERR_OR_NULL(scm))
+ return 0;
+
if (cpu_is_omap24xx()) {
OK, not really related to that patch, but the previous cpu_is_omap24xx
makes me think of that :-)
What about the omap_check_revision used by cpu_is_XXX?
This call is the very first one to require the control module access in
order to get the ID_CODE inside the control module.
So far it still use that ugly hard coded phys -> virtual address macro
that is sued for that.
val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
} else if (cpu_is_am33xx()) {
@@ -49,16 +56,23 @@ int omap_type(void)
} else if (cpu_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
- val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ ret = omap_control_readl(scm, OMAP4_CTRL_MODULE_CORE_STATUS,
+ &val);
I guess you should get rid of these cpu_is_omap44xx and store the
omap_type somewhere to avoid further access to the control module since
there are a couple of places that use that API.
Not necessarily in this patch for sure, but something that might be done
in this series.
Regards,
Benoit
--
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 PATCH 05/11] mfd: omap: control: core system control driver
On 5/25/2012 10:25 AM, Eduardo Valentin wrote:
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device. It is
composed of two control submodules: general control
module and device (padconfiguration) control
module.
In this patch, the children defined are for:
. USB-phy pin control
. Bangap temperature sensor
Device driver is probed with postcore_initcall.
However, as some of the APIs exposed by this driver
may be needed in very early init phase, an early init
class is also available: "early_omap_control".
Signed-off-by: J Keerthy
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
---
.../devicetree/bindings/mfd/omap_control.txt | 44
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/plat-omap/Kconfig |3 +
drivers/mfd/Kconfig|9 +
drivers/mfd/Makefile |1 +
drivers/mfd/omap-control-core.c| 211
include/linux/mfd/omap_control.h | 69 +++
7 files changed, 338 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt
create mode 100644 drivers/mfd/omap-control-core.c
create mode 100644 include/linux/mfd/omap_control.h
diff --git a/Documentation/devicetree/bindings/mfd/omap_control.txt
b/Documentation/devicetree/bindings/mfd/omap_control.txt
new file mode 100644
index 000..46d5e7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -0,0 +1,44 @@
+* Texas Instrument OMAP System Control Module (SCM) bindings
+
+The control module allows software control of various static modes supported by
+the device. The control module controls the settings of various device modules
+through register configuration and internal signals. It also controls the pad
+configuration, pin functional multiplexing, and the routing of internal signals
+(such as PRCM signals or DMA requests) to output pins configured for hardware
+observability.
+
+Required properties:
+- compatible : Should be:
+ - "ti,omap3-control" for OMAP3 support
+ - "ti,omap4-control" for OMAP4 support
+ - "ti,omap5-control" for OMAP5 support
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the control module:
+ Should be "ctrl_module_core";
+
+Sub-nodes:
+- bandgap : contains the bandgap node
+
+ The bindings details of individual bandgap device can be found in:
+ Documentation/devicetree/bindings/thermal/omap_bandgap.txt
+
+- usb : contains the usb phy pin control node
+
+ The only required property for this child is:
+- compatible = "ti,omap4-control-usb";
+
+Examples:
+
+ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = "ti,omap4-control";
+ ti,hwmods = "ctrl_module_core";
+ bandgap {
+ compatible = "ti,omap4460-bandgap";
+ interrupts =<0 126 4>; /* talert */
+ ti,tshut-gpio =<86>; /* tshut */
+ };
+ usb {
+ compatible = "ti,omap4-usb-phy";
+ };
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a2b946d..7dfe5e1 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -52,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+ select ARCH_HAS_CONTROL_MODULE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..222dbad 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,9 @@ menu "TI OMAP Common Features"
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+ bool
+
choice
prompt "OMAP System Type"
default ARCH_OMAP2PLUS
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 11e4438..25a66d8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -795,6 +795,15 @@ config MFD_WL1273_CORE
driver connects the radio-wl1273 V4L2 module and the wl1273
audio codec.
+config MFD_OMAP_CONTROL
+ bool "Texas Instruments OMAP System control module"
+ depends on ARCH_HAS_CONTROL_MODULE
+ help
+ This is the core driver for system control module. This driver
+ is responsible for creating the control module mfd child,
+ like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
+ change for off mode.
+
config MFD_OMAP_USB_HOST
bool "Support OMAP USBHS core driver"
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 05fa538..00f99d6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -106,6 +106,7 @@ obj-$
Re: [RFC PATCH 04/11] OMAP: Add early device for system control module
On 5/25/2012 10:25 AM, Eduardo Valentin wrote:
This is a way to add an early device for system control module.
the code is also requesting for driver registration and probing.
Done at early_initcall because at that time, ioremapping is possible.
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/devices.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9332673..58cc5c3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -40,6 +40,35 @@
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
+static struct resource control_resources[] = {
+ [0] = {
+ .start = 0x4a002000,
+ .end= 0x4a0027ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
I guess you should be able to do use DT to build the early device as well.
It will avoid hard coding some physical address inside the devices.
Regards,
Benoit
+static struct platform_device control_device = {
+ .name = "omap-control-core",
+ .id = 0,
+ .resource = control_resources,
+ .num_resources = ARRAY_SIZE(control_resources),
+};
+
+static struct platform_device *early_devices[] __initdata = {
+ &control_device,
+};
+
+static int __init plat_early_device_setup(void)
+{
+ early_platform_add_devices(early_devices,
+ ARRAY_SIZE(early_devices));
+ early_platform_driver_register_all("early_omap_control");
+ early_platform_driver_probe("early_omap_control", 1, false);
+
+ return 0;
+}
+early_initcall(plat_early_device_setup);
+
static int omap_init_control(void)
{
struct omap_hwmod *oh;
--
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 PATCH 03/11] arm: omap: device: create a device for system control module
On 5/25/2012 10:25 AM, Eduardo Valentin wrote:
From: Kishon Vijay Abraham I
Extracts the device data from hwmod database and create a platform device
using omap device build.
The device build is done during postcore_initcall.
Do you still need that since you are supporting only DT?
The device will be built automatically in the DT case.
Regards,
Benoit
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/devices.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 152c266..9332673 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -40,6 +40,32 @@
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
+static int omap_init_control(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ const char *oh_name, *name;
+
+ oh_name = "ctrl_module_core";
+ name = "omap-control-core";
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("Could not lookup hwmod for %s\n", oh_name);
+ return PTR_ERR(oh);
+ }
+
+ pdev = omap_device_build(name, -1, oh, NULL, 0, NULL, 0, true);
+ if (IS_ERR(pdev)) {
+ pr_err("Could not build omap_device for %s %s\n",
+ name, oh_name);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
+postcore_initcall(omap_init_control);
+
static int __init omap3_l3_init(void)
{
struct omap_hwmod *oh;
--
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 PATCH 00/11] OMAP System Control Module
Hi.
On 05/25/2012 03:11 PM, Valentin, Eduardo wrote:
> Konstantin,
>
> On Fri, May 25, 2012 at 1:50 PM, Konstantin Baydarov
> wrote:
>> Hi.
>>
>> On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
>>> Hello Paul and Tony,
>>>
>>> This is a series of patches adding a basic support for system control
>>> module,
>>> on OMAP4+ context. It is a working in progress, but I wanted to share
>>> already
>>> to get your feedback.
>>>
>>> I've modeled the driver as an MFD. You will see in this series:
>>> . A rework of the system control module header (patch from Santosh, picked
>>> from the list)
>>> . Device creation for control module core
>>> . Early device creation for control module core
>>> . The MFD core driver for system control module
>>> . The MFD child for usb-phy pin control
>>> . The MFD child for bandgap sensor
>>> . Very early exposure of OMAP4 thermal zone
>>> . All added drivers are only supporting DT probing
>>> . The series is based on linux-omap master, as it has the hwmod entries for
>>> SCM.
>>>
>>> The overall idea of this series is to put in place the infrastructure. It is
>>> not touching nor removing the existing APIs under mach-omap2/control.c for
>>> now.
>>> But the target is to have these APIs moved to the MFD core driver.
>>>
>>> For early access, like ID checking, I have written the platform driver
>>> as an early platform driver and you will see also early device addition
>>> and probing under device.c for this case. This is of course a proposal.
>>> I see that there are people that thing this is a bit of an overkill.
>>> Konstantin (CCd) was proposing a simpler solution by having
>>> APIs with early_* prefixes, and solve the IO address mapping with
>>> a DT entry, for instance. But feel free to propose better ways.
>> In my latest version I got rid from early API set, check out patch for V3
>> patch set.
>> I'll attach patch for current version later.
>
> Please send it across so we can compare your approach with the one
> present in this series.
Moved control module window remap to early_initcall to allow usage of
control module API very early during kernel initialization.
Switched omap_type() to omap-control-core.c API.
Signed-off-by: Konstantin Baydarov
Index: omap-thermal/drivers/mfd/omap-control-core.c
===
--- omap-thermal.orig/drivers/mfd/omap-control-core.c
+++ omap-thermal/drivers/mfd/omap-control-core.c
@@ -31,12 +31,16 @@
#include
#include
+#include
+#include
+
static struct omap_control *omap_control_module;
+struct omap_control omap_control_data;
/**
* omap_control_readl: Read a single omap control module register.
*
- * @dev: device to read from.
+ * @dev: unused - there is only one controle module
* @reg: register to read.
* @val: output with register value.
*
@@ -44,7 +48,7 @@ static struct omap_control *omap_control
*/
int omap_control_readl(struct device *dev, u32 reg, u32 *val)
{
- struct omap_control *omap_control = dev_get_drvdata(dev);
+ struct omap_control *omap_control = omap_control_module;
if (!omap_control)
return -EINVAL;
@@ -58,7 +62,7 @@ EXPORT_SYMBOL_GPL(omap_control_readl);
/**
* omap_control_writel: Write a single omap control module register.
*
- * @dev: device to read from.
+ * @dev: unused - there is only one controle module
* @val: value to write.
* @reg: register to write to.
*
@@ -66,7 +70,7 @@ EXPORT_SYMBOL_GPL(omap_control_readl);
*/
int omap_control_writel(struct device *dev, u32 val, u32 reg)
{
- struct omap_control *omap_control = dev_get_drvdata(dev);
+ struct omap_control *omap_control = omap_control_module;
unsigned long flags;
if (!omap_control)
@@ -130,40 +134,26 @@ static const struct of_device_id of_omap
static int __devinit omap_control_probe(struct platform_device *pdev)
{
- struct resource *res;
- void __iomem *base;
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct omap_control *omap_control;
- omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
- if (!omap_control) {
- dev_err(dev, "not enough memory for omap_control\n");
- return -ENOMEM;
- }
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "missing memory base resource\n");
- return -EINVAL;
- }
-
- base = devm_request_and_ioremap(dev, res);
- if (!base) {
+ if (!omap_control_module) {
dev_err(dev, "ioremap failed\n");
return -EADDRNOTAVAIL;
}
+ omap_control = omap_control_module;
- omap_control->base = base;
omap_control->dev = dev;
spin_lock_init(&omap_control->reg_lock);
platform_set_drvdata(pdev, omap_control);
- omap_control_module = omap_control;
return of_platform
Re: [RFC PATCH 04/11] OMAP: Add early device for system control module
Hi.
On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
> This is a way to add an early device for system control module.
> the code is also requesting for driver registration and probing.
> Done at early_initcall because at that time, ioremapping is possible.
>
> Signed-off-by: Eduardo Valentin
> ---
> arch/arm/mach-omap2/devices.c | 29 +
> 1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 9332673..58cc5c3 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -40,6 +40,35 @@
> #define L3_MODULES_MAX_LEN 12
> #define L3_MODULES 3
>
> +static struct resource control_resources[] = {
> + [0] = {
> + .start = 0x4a002000,
> + .end= 0x4a0027ff,
> + .flags = IORESOURCE_MEM,
> + },
> +};
Init control module platform device resources from device tree instead of
hard-coding them.
Prevent control module driver registering itself second time after it has
already been registered by early_platform_driver_register_all().
Signed-off-by: Konstantin Baydarov
Index: omap-thermal/arch/arm/boot/dts/omap4.dtsi
===
--- omap-thermal.orig/arch/arm/boot/dts/omap4.dtsi
+++ omap-thermal/arch/arm/boot/dts/omap4.dtsi
@@ -275,7 +275,10 @@
ctrl_module_core: ctrl_module_core@4a002000 {
compatible = "ti,omap4-control";
+ #address-cells = <1>;
+ #size-cells = <1>;
ti,hwmods = "ctrl_module_core";
+ reg = <0x4a002000 0x1000>;
bandgap {
compatible = "ti,omap4460-bandgap";
interrupts = <0 126 4>; /* talert */
Index: omap-thermal/arch/arm/mach-omap2/devices.c
===
--- omap-thermal.orig/arch/arm/mach-omap2/devices.c
+++ omap-thermal/arch/arm/mach-omap2/devices.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,6 +41,7 @@
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
+#if 0
static struct resource control_resources[] = {
[0] = {
.start = 0x4a002000,
@@ -47,6 +49,17 @@ static struct resource control_resources
.flags = IORESOURCE_MEM,
},
};
+#endif
+
+static const struct of_device_id of_omap_control_match[] = {
+ { .compatible = "ti,omap3-control", },
+ { .compatible = "ti,omap4-control", },
+ { .compatible = "ti,omap5-control", },
+ { },
+};
+
+static struct resource control_resources[1];
+
static struct platform_device control_device = {
.name = "omap-control-core",
.id = 0,
@@ -58,8 +71,56 @@ static struct platform_device *early_dev
&control_device,
};
+int __init omap_control_of_init(struct device_node *node,
+struct device_node *parent)
+{
+ struct resource res;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_address_to_resource(node, 0, &res)) {
+ WARN(1, "unable to get intc registers\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+void __init of_omap_control_init(const struct of_device_id *matches)
+{
+ struct device_node *np;
+ struct property *pp = 0;
+ unsigned long phys_base = 0;
+ size_t mapsize = 0;
+
+ for_each_matching_node(np, matches) {
+
+ pp = of_find_property(np, "reg", NULL);
+ if(pp) {
+// printk("\t\t of_omap_control_init(): ioremap %x
\n", be32_to_cpup(pp->value));
+// printk("\t\t of_omap_control_init(): 2 value %x
\n", be32_to_cpup( (char*)pp->value + 4 ) );
+// printk("\t\t of_omap_control_init(): length %x
\n", pp->length);
+
+ phys_base = (resource_size_t)be32_to_cpup(pp->value);
+ mapsize = (size_t)be32_to_cpup(
(void*)((char*)pp->value + 4) );
+#if 0
+ omap_control_data.base = ioremap(phys_base, mapsize);
+ if(omap_control_data.base)
+ omap_control_module = &omap_control_data;
+#endif
+ control_resources[0].start = phys_base;
+ control_resources[0].end = phys_base + mapsize;
+ control_resources[0].flags = IORESOURCE_MEM;
+ printk("\t\t of_omap_control_init(): start addr %x
\n", control_resources[0].start);
+ printk("\t\t of_omap_control_init(): end addr %x
\n", control_resources[0].end);
+ }
+ }
+}
+
static int __init plat_early_device_setup(void)
{
+ of_omap_control_init(of_omap_control_match);
Re: [RFC PATCH 04/11] OMAP: Add early device for system control module
Hello,
On Fri, May 25, 2012 at 2:32 PM, Konstantin Baydarov
wrote:
> Hi , Eduardo.
>
> On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
>> This is a way to add an early device for system control module.
>> the code is also requesting for driver registration and probing.
>> Done at early_initcall because at that time, ioremapping is possible.
OK. Which debug config you have?
In any case, that can be solved by not requesting the resource and
passing the address area by other means.
>>
>> Signed-off-by: Eduardo Valentin
>> ---
>> arch/arm/mach-omap2/devices.c | 29 +
>> 1 files changed, 29 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
>> index 9332673..58cc5c3 100644
>> --- a/arch/arm/mach-omap2/devices.c
>> +++ b/arch/arm/mach-omap2/devices.c
>> @@ -40,6 +40,35 @@
>> #define L3_MODULES_MAX_LEN 12
>> #define L3_MODULES 3
>>
>> +static struct resource control_resources[] = {
>> + [0] = {
>> + .start = 0x4a002000,
>> + .end = 0x4a0027ff,
>> + .flags = IORESOURCE_MEM,
>> + },
>> +};
>> +static struct platform_device control_device = {
>> + .name = "omap-control-core",
>> + .id = 0,
>> + .resource = control_resources,
>> + .num_resources = ARRAY_SIZE(control_resources),
>> +};
>> +
>> +static struct platform_device *early_devices[] __initdata = {
>> + &control_device,
>> +};
>> +
>> +static int __init plat_early_device_setup(void)
>> +{
>> + early_platform_add_devices(early_devices,
>> + ARRAY_SIZE(early_devices));
>> + early_platform_driver_register_all("early_omap_control");
>> + early_platform_driver_probe("early_omap_control", 1, false);
> I checked out git://gitorious.org/omap-thermal/omap-thermal.git omap_scm_dev.
> Looks like that calling devm_kzalloc() and platform_get_resource() from
> early_initcall is too early.
> I get following backtrace (probably the backtrace is kernel config dependent):
> ...
> [ 0.198455] [] (unwind_backtrace+0x0/0xe0) from []
> (do_raw_spin_lock+0x20/0x134)
> [ 0.207977] [] (do_raw_spin_lock+0x20/0x134) from []
> (_raw_spin_lock_irqsave+0x58/0x64)
> [ 0.218109] [] (_raw_spin_lock_irqsave+0x58/0x64) from
> [] (devres_add+0x18/0x38)
> [ 0.227600] [] (devres_add+0x18/0x38) from []
> (devm_kzalloc+0x50/0x5c)
> [ 0.236206] [] (devm_kzalloc+0x50/0x5c) from []
> (omap_control_probe+0x20/0xe4)
> [ 0.245544] [] (omap_control_probe+0x20/0xe4) from []
> (early_platform_driver_probe+0x1ac/0x23c)
> [ 0.256378] [] (early_platform_driver_probe+0x1ac/0x23c) from
> [] (plat_early_device_setup+0x2c/0x3c)
> [ 0.267700] [] (plat_early_device_setup+0x2c/0x3c) from
> [] (do_one_initcall+0x90/0x164)
> [ 0.277801] [] (do_one_initcall+0x90/0x164) from []
> (kernel_init+0x54/0x1a4)
> [ 0.286956] [] (kernel_init+0x54/0x1a4) from []
> (kernel_thread_exit+0x0/0x8)
> [ 0.296203] [ cut here ]
> [ 0.301086] WARNING: at include/linux/kref.h:41 kobject_get+0x24/0x48()
> [ 0.308044] [] (unwind_backtrace+0x0/0xe0) from []
> (warn_slowpath_common+0x48/0x60)
> [ 0.317871] [] (warn_slowpath_common+0x48/0x60) from
> [] (warn_slowpath_null+0x18/0x1c)
> [ 0.327941] [] (warn_slowpath_null+0x18/0x1c) from []
> (kobject_get+0x24/0x48)
> [ 0.337219] [] (kobject_get+0x24/0x48) from []
> (get_device+0x14/0x1c)
> [ 0.345764] [] (get_device+0x14/0x1c) from []
> (device_add+0xc4/0x594)
> [ 0.354370] [] (device_add+0xc4/0x594) from []
> (of_platform_device_create_pdata+0x5c/0x7c)
> [ 0.364807] [] (of_platform_device_create_pdata+0x5c/0x7c) from
> [] (of_platform_bus_create+0x1c0/0x258)
> [ 0.376403] [] (of_platform_bus_create+0x1c0/0x258) from
> [] (of_platform_populate+0x5c/0x88)
> [ 0.387023] [] (of_platform_populate+0x5c/0x88) from
> [] (early_platform_driver_probe+0x1ac/0x23c)
> [ 0.398101] [] (early_platform_driver_probe+0x1ac/0x23c) from
> [] (plat_early_device_setup+0x2c/0x3c)
> [ 0.409423] [] (plat_early_device_setup+0x2c/0x3c) from
> [] (do_one_initcall+0x90/0x164)
> [ 0.419586] [] (do_one_initcall+0x90/0x164) from []
> (kernel_init+0x54/0x1a4)
> [ 0.428771] [] (kernel_init+0x54/0x1a4) from []
> (kernel_thread_exit+0x0/0x8)
> [ 0.437957] ---[ end trace da227214a82491b7 ]--
> ...
>
> BR,
> Konstantin Baydarov.
>
>> +
>> + return 0;
>> +}
>> +early_initcall(plat_early_device_setup);
>> +
>> static int omap_init_control(void)
>> {
>> struct omap_hwmod *oh;
>
--
Eduardo Valentin
--
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 PATCH 04/11] OMAP: Add early device for system control module
Hi , Eduardo.
On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
> This is a way to add an early device for system control module.
> the code is also requesting for driver registration and probing.
> Done at early_initcall because at that time, ioremapping is possible.
>
> Signed-off-by: Eduardo Valentin
> ---
> arch/arm/mach-omap2/devices.c | 29 +
> 1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 9332673..58cc5c3 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -40,6 +40,35 @@
> #define L3_MODULES_MAX_LEN 12
> #define L3_MODULES 3
>
> +static struct resource control_resources[] = {
> + [0] = {
> + .start = 0x4a002000,
> + .end= 0x4a0027ff,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +static struct platform_device control_device = {
> + .name = "omap-control-core",
> + .id = 0,
> + .resource = control_resources,
> + .num_resources = ARRAY_SIZE(control_resources),
> +};
> +
> +static struct platform_device *early_devices[] __initdata = {
> + &control_device,
> +};
> +
> +static int __init plat_early_device_setup(void)
> +{
> + early_platform_add_devices(early_devices,
> +ARRAY_SIZE(early_devices));
> + early_platform_driver_register_all("early_omap_control");
> + early_platform_driver_probe("early_omap_control", 1, false);
I checked out git://gitorious.org/omap-thermal/omap-thermal.git omap_scm_dev.
Looks like that calling devm_kzalloc() and platform_get_resource() from
early_initcall is too early.
I get following backtrace (probably the backtrace is kernel config dependent):
...
[0.198455] [] (unwind_backtrace+0x0/0xe0) from []
(do_raw_spin_lock+0x20/0x134)
[0.207977] [] (do_raw_spin_lock+0x20/0x134) from []
(_raw_spin_lock_irqsave+0x58/0x64)
[0.218109] [] (_raw_spin_lock_irqsave+0x58/0x64) from
[] (devres_add+0x18/0x38)
[0.227600] [] (devres_add+0x18/0x38) from []
(devm_kzalloc+0x50/0x5c)
[0.236206] [] (devm_kzalloc+0x50/0x5c) from []
(omap_control_probe+0x20/0xe4)
[0.245544] [] (omap_control_probe+0x20/0xe4) from []
(early_platform_driver_probe+0x1ac/0x23c)
[0.256378] [] (early_platform_driver_probe+0x1ac/0x23c) from
[] (plat_early_device_setup+0x2c/0x3c)
[0.267700] [] (plat_early_device_setup+0x2c/0x3c) from
[] (do_one_initcall+0x90/0x164)
[0.277801] [] (do_one_initcall+0x90/0x164) from []
(kernel_init+0x54/0x1a4)
[0.286956] [] (kernel_init+0x54/0x1a4) from []
(kernel_thread_exit+0x0/0x8)
[0.296203] [ cut here ]
[0.301086] WARNING: at include/linux/kref.h:41 kobject_get+0x24/0x48()
[0.308044] [] (unwind_backtrace+0x0/0xe0) from []
(warn_slowpath_common+0x48/0x60)
[0.317871] [] (warn_slowpath_common+0x48/0x60) from []
(warn_slowpath_null+0x18/0x1c)
[0.327941] [] (warn_slowpath_null+0x18/0x1c) from []
(kobject_get+0x24/0x48)
[0.337219] [] (kobject_get+0x24/0x48) from []
(get_device+0x14/0x1c)
[0.345764] [] (get_device+0x14/0x1c) from []
(device_add+0xc4/0x594)
[0.354370] [] (device_add+0xc4/0x594) from []
(of_platform_device_create_pdata+0x5c/0x7c)
[0.364807] [] (of_platform_device_create_pdata+0x5c/0x7c) from
[] (of_platform_bus_create+0x1c0/0x258)
[0.376403] [] (of_platform_bus_create+0x1c0/0x258) from
[] (of_platform_populate+0x5c/0x88)
[0.387023] [] (of_platform_populate+0x5c/0x88) from []
(early_platform_driver_probe+0x1ac/0x23c)
[0.398101] [] (early_platform_driver_probe+0x1ac/0x23c) from
[] (plat_early_device_setup+0x2c/0x3c)
[0.409423] [] (plat_early_device_setup+0x2c/0x3c) from
[] (do_one_initcall+0x90/0x164)
[0.419586] [] (do_one_initcall+0x90/0x164) from []
(kernel_init+0x54/0x1a4)
[0.428771] [] (kernel_init+0x54/0x1a4) from []
(kernel_thread_exit+0x0/0x8)
[0.437957] ---[ end trace da227214a82491b7 ]--
...
BR,
Konstantin Baydarov.
> +
> + return 0;
> +}
> +early_initcall(plat_early_device_setup);
> +
> static int omap_init_control(void)
> {
> struct omap_hwmod *oh;
--
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 PATCH 00/11] OMAP System Control Module
Konstantin, On Fri, May 25, 2012 at 1:50 PM, Konstantin Baydarov wrote: > Hi. > > On 05/25/2012 12:25 PM, Eduardo Valentin wrote: >> Hello Paul and Tony, >> >> This is a series of patches adding a basic support for system control module, >> on OMAP4+ context. It is a working in progress, but I wanted to share already >> to get your feedback. >> >> I've modeled the driver as an MFD. You will see in this series: >> . A rework of the system control module header (patch from Santosh, picked >> from the list) >> . Device creation for control module core >> . Early device creation for control module core >> . The MFD core driver for system control module >> . The MFD child for usb-phy pin control >> . The MFD child for bandgap sensor >> . Very early exposure of OMAP4 thermal zone >> . All added drivers are only supporting DT probing >> . The series is based on linux-omap master, as it has the hwmod entries for >> SCM. >> >> The overall idea of this series is to put in place the infrastructure. It is >> not touching nor removing the existing APIs under mach-omap2/control.c for >> now. >> But the target is to have these APIs moved to the MFD core driver. >> >> For early access, like ID checking, I have written the platform driver >> as an early platform driver and you will see also early device addition >> and probing under device.c for this case. This is of course a proposal. >> I see that there are people that thing this is a bit of an overkill. >> Konstantin (CCd) was proposing a simpler solution by having >> APIs with early_* prefixes, and solve the IO address mapping with >> a DT entry, for instance. But feel free to propose better ways. > In my latest version I got rid from early API set, check out patch for V3 > patch set. > I'll attach patch for current version later. Please send it across so we can compare your approach with the one present in this series. > > BR, > Konstantin Baydarov. > >> >> This code has been ripped off from the Android 3.1 branch. I have rewritten >> a couple of things, but the major driver functions and API's entries are >> kept. >> >> So, based on this series, I see as a TODO list, for system control core >> driver: >> - Start to move all the existing APIs under mach-omap2/control.c to the mfd >> core. >> - Rewrite the users of the existing APIs, mentioned on previous item >> Once we decide the API and agree on how to deal with early calls. >> - Add remaining children (from top of my head, the CAM is one of them, >> but I also think we should prob have one for HWOBS for instance) >> - Test on boards that use the existing APIs. >> >> TODO list for bandgap driver: >> - Improve thermal zone definition for OMAP4 >> - Introduce the thermal zones for OMAP5 >> >> Amit, due to hwmod dep, I didn't include any cooling binding in this series, >> based on the generic CPU cooling device. >> >> Overall series has been tested only with panda board OMAP4460. >> >> Your comments are welcome. >> >> All best, >> >> Eduardo Valentin (9): >> ARM: OMAP: expose control.h to mach area >> OMAP: Add early device for system control module >> mfd: omap: control: core system control driver >> OMAP2+: use control module mfd driver in omap_type >> mfd: omap: control: usb-phy: introduce the ctrl-module usb driver >> ARM: OMAP4+: Adding the temperature sensor register set bit fields >> ARM: OMAP4+: thermal: introduce bandgap temperature sensor >> omap4: thermal: add basic CPU thermal zone >> ARM: DT: Add support to system control module for OMAP4 >> >> Kishon Vijay Abraham I (1): >> arm: omap: device: create a device for system control module >> >> Santosh Shilimkar (1): >> ARM: OMAP4: Remove un-used control module headers and defines. >> >> .../devicetree/bindings/mfd/omap_control.txt | 44 + >> .../devicetree/bindings/thermal/omap_bandgap.txt | 27 + >> arch/arm/boot/dts/omap4.dtsi | 13 + >> arch/arm/mach-omap2/Kconfig | 1 + >> arch/arm/mach-omap2/am35xx-emac.c | 2 +- >> arch/arm/mach-omap2/board-3430sdp.c | 2 +- >> arch/arm/mach-omap2/board-4430sdp.c | 2 +- >> arch/arm/mach-omap2/board-am3517crane.c | 2 +- >> arch/arm/mach-omap2/board-am3517evm.c | 2 +- >> arch/arm/mach-omap2/board-apollon.c | 2 +- >> arch/arm/mach-omap2/board-cm-t3517.c | 2 +- >> arch/arm/mach-omap2/board-h4.c | 2 +- >> arch/arm/mach-omap2/board-igep0020.c | 2 +- >> arch/arm/mach-omap2/board-ldp.c | 2 +- >> arch/arm/mach-omap2/board-omap3logic.c | 2 +- >> arch/arm/mach-omap2/board-omap4panda.c | 2 +- >> arch/arm/mach-omap2/board-omap4pcm049.c | 2 +- >> arch/arm/mach-omap2/clock2420_data.c | 2 +- >> arch/arm/mach-omap2/clock2430_data.c | 2 +- >> arch/arm/mach-omap2/clock3x
Re: [RFC PATCH 00/11] OMAP System Control Module
Hi. On 05/25/2012 12:25 PM, Eduardo Valentin wrote: > Hello Paul and Tony, > > This is a series of patches adding a basic support for system control module, > on OMAP4+ context. It is a working in progress, but I wanted to share already > to get your feedback. > > I've modeled the driver as an MFD. You will see in this series: > . A rework of the system control module header (patch from Santosh, picked > from the list) > . Device creation for control module core > . Early device creation for control module core > . The MFD core driver for system control module > . The MFD child for usb-phy pin control > . The MFD child for bandgap sensor > . Very early exposure of OMAP4 thermal zone > . All added drivers are only supporting DT probing > . The series is based on linux-omap master, as it has the hwmod entries for > SCM. > > The overall idea of this series is to put in place the infrastructure. It is > not touching nor removing the existing APIs under mach-omap2/control.c for > now. > But the target is to have these APIs moved to the MFD core driver. > > For early access, like ID checking, I have written the platform driver > as an early platform driver and you will see also early device addition > and probing under device.c for this case. This is of course a proposal. > I see that there are people that thing this is a bit of an overkill. > Konstantin (CCd) was proposing a simpler solution by having > APIs with early_* prefixes, and solve the IO address mapping with > a DT entry, for instance. But feel free to propose better ways. In my latest version I got rid from early API set, check out patch for V3 patch set. I'll attach patch for current version later. BR, Konstantin Baydarov. > > This code has been ripped off from the Android 3.1 branch. I have rewritten > a couple of things, but the major driver functions and API's entries are kept. > > So, based on this series, I see as a TODO list, for system control core > driver: > - Start to move all the existing APIs under mach-omap2/control.c to the mfd > core. > - Rewrite the users of the existing APIs, mentioned on previous item > Once we decide the API and agree on how to deal with early calls. > - Add remaining children (from top of my head, the CAM is one of them, > but I also think we should prob have one for HWOBS for instance) > - Test on boards that use the existing APIs. > > TODO list for bandgap driver: > - Improve thermal zone definition for OMAP4 > - Introduce the thermal zones for OMAP5 > > Amit, due to hwmod dep, I didn't include any cooling binding in this series, > based on the generic CPU cooling device. > > Overall series has been tested only with panda board OMAP4460. > > Your comments are welcome. > > All best, > > Eduardo Valentin (9): > ARM: OMAP: expose control.h to mach area > OMAP: Add early device for system control module > mfd: omap: control: core system control driver > OMAP2+: use control module mfd driver in omap_type > mfd: omap: control: usb-phy: introduce the ctrl-module usb driver > ARM: OMAP4+: Adding the temperature sensor register set bit fields > ARM: OMAP4+: thermal: introduce bandgap temperature sensor > omap4: thermal: add basic CPU thermal zone > ARM: DT: Add support to system control module for OMAP4 > > Kishon Vijay Abraham I (1): > arm: omap: device: create a device for system control module > > Santosh Shilimkar (1): > ARM: OMAP4: Remove un-used control module headers and defines. > > .../devicetree/bindings/mfd/omap_control.txt | 44 + > .../devicetree/bindings/thermal/omap_bandgap.txt | 27 + > arch/arm/boot/dts/omap4.dtsi | 13 + > arch/arm/mach-omap2/Kconfig|1 + > arch/arm/mach-omap2/am35xx-emac.c |2 +- > arch/arm/mach-omap2/board-3430sdp.c|2 +- > arch/arm/mach-omap2/board-4430sdp.c|2 +- > arch/arm/mach-omap2/board-am3517crane.c|2 +- > arch/arm/mach-omap2/board-am3517evm.c |2 +- > arch/arm/mach-omap2/board-apollon.c|2 +- > arch/arm/mach-omap2/board-cm-t3517.c |2 +- > arch/arm/mach-omap2/board-h4.c |2 +- > arch/arm/mach-omap2/board-igep0020.c |2 +- > arch/arm/mach-omap2/board-ldp.c|2 +- > arch/arm/mach-omap2/board-omap3logic.c |2 +- > arch/arm/mach-omap2/board-omap4panda.c |2 +- > arch/arm/mach-omap2/board-omap4pcm049.c|2 +- > arch/arm/mach-omap2/clock2420_data.c |2 +- > arch/arm/mach-omap2/clock2430_data.c |2 +- > arch/arm/mach-omap2/clock3xxx_data.c |2 +- > arch/arm/mach-omap2/clock44xx_data.c |2 +- > arch/arm/mach-omap2/common.c |2 +- > arch/arm/mach-omap2/control.c |2 +- > arch/arm/mach-omap2/cpuidle34xx.c |
RE: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hi Tony, On Fri, May 25, 2012 at 12:56:59, Tony Lindgren wrote: > * Paul Walmsley [120523 17:55]: > > On Tue, 22 May 2012, Tony Lindgren wrote: > > > > > > Unfortunately for many of the older boards these values will probably > > > remain unknown. > > > > > > So the better approach here is to just disable frequency scaling > > > for these cases. Otherwise we'll be breaking old boards with smsc911x > > > where the timings for the FPGA controlling smsc911x are unknown. > > > > > > If we somehow manage to get those values without breaking support for > > > these boards, then yes I agree we should deprecate hardcoded and > > > bootloader values. > > > > I was thinking that if we log the register values supplied by the > > bootloader to the console, then someone can write a patch to the board > > file or DT data to set those register values explicitly in the kernel, > > once they're known. Or at least just report them to the l-o list. > > > > So then that should reduce the problem cases down to boards which no one > > reports the data to the mailing list within a few mainline kernel releases > > -- i.e., boards which are unmaintained. For those boards, I'd suggest > > that we just drop GPMC support until someone shows up who has a board and > > can test-boot it. Or just drop the board completely ;-) > > OK seems fair to me. It still allows us to boot the older boards with > minimal changes (but without L3 frequency scaling). > > Sounds like those registers should be dumped only if no configuration > is specified to avoid spamming the console. Shall I take it as go ahead to create a patch on Documentation/feature-removal-schedule.txt in the next version of gpmc series stating that implicit boot loader GPMC timings will be removed in three Kernel releases ? (i.e. as per Paul's suggestion, along with other points he has mentioned) Regards Afzal -- 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 08/10] arm: omap4panda: Add support for omap4iss camera
* Sergio Aguirre [120523 21:49]: > Hi Tony, > > On Tue, May 8, 2012 at 6:46 PM, Tony Lindgren wrote: > > * Sergio Aguirre [120502 08:21]: > >> This adds support for camera interface with the support for > >> following sensors: > >> > >> - OV5640 > >> - OV5650 > > > > It seems that at this point we should initialize new things like this > > with DT only. We don't quite yet have the muxing in place, but I'd > > rather not add yet another big platform_data file for something that > > does not even need to be there for DT booted devices. > > Ok. > > I'll look at that. > > By the way, I've been very out of the loop on al DT related development.. > > Are these instructions valid for current master k.org branch? > > http://omappedia.org/wiki/Device_Tree#Booting_with_DT_blob Yeah seems about right. 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
[PATCH 3/3] watchdog: omap_wdt: add device tree support
From: Xiao Jiang
Add device table for omap_wdt to support dt.
Signed-off-by: Xiao Jiang
---
drivers/watchdog/omap_wdt.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..d98c615 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -430,6 +430,13 @@ static int omap_wdt_resume(struct platform_device *pdev)
#defineomap_wdt_resume NULL
#endif
+static const struct of_device_id omap_wdt_of_match[] = {
+ { .compatible = "ti,omap3-wdt", },
+ { .compatible = "ti,omap4-wdt", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_wdt_of_match);
+
static struct platform_driver omap_wdt_driver = {
.probe = omap_wdt_probe,
.remove = __devexit_p(omap_wdt_remove),
@@ -439,6 +446,7 @@ static struct platform_driver omap_wdt_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "omap_wdt",
+ .of_match_table = omap_wdt_of_match,
},
};
--
1.7.3
--
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] arm/dts: add wdt node for omap3 and omap4
From: Xiao Jiang
Add wdt node to support dt.
Signed-off-by: Xiao Jiang
---
arch/arm/boot/dts/omap3.dtsi |5 +
arch/arm/boot/dts/omap4.dtsi |5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..039df5c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,10 @@
compatible = "ti,omap3-hsmmc";
ti,hwmods = "mmc3";
};
+
+ wdt: wdt@48314000{
+ compatible = "ti,omap3-wdt";
+ ti,hwmods = "wd_timer2";
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d01403d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,10 @@
ti,hwmods = "mmc5";
ti,needs-special-reset;
};
+
+ wdt: wdt@4a314000{
+ compatible = "ti,omap4-wdt";
+ ti,hwmods = "wd_timer2";
+ };
};
};
--
1.7.3
--
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] OMAP: avoid build wdt platform device if with dt support
From: Xiao Jiang If provided dt support, then skip add wdt platform device as usual. Signed-off-by: Xiao Jiang --- arch/arm/mach-omap2/devices.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index ae62ece..80d7e3f 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -759,7 +759,7 @@ static int __init omap_init_wdt(void) char *oh_name = "wd_timer2"; char *dev_name = "omap_wdt"; - if (!cpu_class_is_omap2()) + if (!cpu_class_is_omap2() || of_have_populated_dt()) return 0; oh = omap_hwmod_lookup(oh_name); -- 1.7.3 -- 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 04/39] ARM: OMAP2+: gpmc: Acquire NAND CS value
* Mohammed, Afzal [120514 03:37]: > > Hi Tony, > > I am planning to provide actual CS # used for NAND on above boards instead of > finding the value at runtime. Is there any reason that NAND CS# is found out > at runtime ? (hence remove necessity of omap_nand_flash_init()). Yes makes sense. All the board specific data like that should come from device tree eventually. 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] OMAP4: Adding ID for OMAP4460 ES1.1
* Ryazantsev, Volodymyr [120515 04:38]: > Hi Tony, > > Could you please take this patch. > Its absence raises some issues like Errata maintenance. This is already in mainline as commit 33ee0db53994a574b76e0261fc9a3daf71f4b0d7. 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 0/2] OMAPDSS: write-through caching support for omapfb
On Thu, May 24, 2012 at 10:43 AM, Tomi Valkeinen wrote:
> On Tue, 2012-05-22 at 22:54 +0300, Siarhei Siamashka wrote:
> I ran my own fb perf test on omap3 overo board ("perf" test in
> https://gitorious.org/linux-omap-dss2/omapfb-tests) :
>
> vram_cache=n:
>
> sequential_horiz_singlepixel_read: 25198080 pix, 4955475 us, 5084897 pix/s
> sequential_horiz_singlepixel_write: 434634240 pix, 4081146 us, 106498086 pix/s
> sequential_vert_singlepixel_read: 20106240 pix, 4970611 us, 4045023 pix/s
> sequential_vert_singlepixel_write: 98572800 pix, 4985748 us, 19770915 pix/s
> sequential_line_read: 40734720 pix, 4977906 us, 8183103 pix/s
> sequential_line_write: 1058580480 pix, 5024628 us, 210678378 pix/s
> nonsequential_singlepixel_write: 17625600 pix, 4992828 us, 3530183 pix/s
> nonsequential_singlepixel_read: 9661440 pix, 4952973 us, 1950634 pix/s
>
> vram_cache=y:
>
> sequential_horiz_singlepixel_read: 270389760 pix, 4994154 us, 54141253 pix/s
> sequential_horiz_singlepixel_write: 473149440 pix, 3932801 us, 120308512 pix/s
> sequential_vert_singlepixel_read: 18147840 pix, 4976226 us, 3646908 pix/s
> sequential_vert_singlepixel_write: 100661760 pix, 4993164 us, 20159914 pix/s
> sequential_line_read: 285143040 pix, 4917267 us, 57988114 pix/s
> sequential_line_write: 876710400 pix, 5012146 us, 174917171 pix/s
> nonsequential_singlepixel_write: 17625600 pix, 4977967 us, 3540722 pix/s
> nonsequential_singlepixel_read: 9661440 pix, 4944885 us, 1953825 pix/s
>
> These also show quite a bit of improvement in some read cases.
> Interestingly some of the write cases are also faster.
>
> Reading pixels vertically is slower with vram_cache. I guess this is
> because the cache causes some overhead, and we always miss the cache so
> the caching is just wasted time.
On a positive side, nobody is normally accessing memory in this way.
It is a well known performance anti-pattern.
> I would've also presumed the difference in sequential_line_write would
> be bigger. write-through is effectively no-cache for writes, right?
Write-through cache is still using write combining buffer for memory
writes. So I would actually expect the performance to be the same.
> If the user of the fb just writes to the fb and vram_cache=y, it means
> that the cache is filled with pixel data that is never used, thus
> lowering the performance of all other programs?
This is true only for write-allocate. We want the framebuffer to be
cacheable as write-through, allocate on read, no allocate on write.
Sure, when we are reading from the cached framebuffer, some useful
data may be evicted from cache. But if we are not caching the
framebuffer, any readers suffer from a huge performance penalty.
That's the reason why shadow framebuffer (a poor man's software
workaround) is implemented in Xorg server. And if we use a shadow
framebuffer (in normal write-back cached memory), we already have the
same or worse cache eviction problems when compared to the cached
framebuffer. I could not find any use case or benchmark where shadow
framebuffer would perform better than write-through cached framebuffer
on OMAP3 hardware.
Maybe a bit more details about the shadow framebuffer would be useful.
That's just one level above the framebuffer in the graphics stack for
linux desktop. And many of the performance issues happen exactly on
the boundary between different pieces of software when they are
developed independently. Knowing how the framebuffer is used in the
real world applications (and I assume X server is one of them) may
provide some insights about how to improve the framebuffer on the
kernel side.
Here the shadow framebuffer is initialized:
http://cgit.freedesktop.org/xorg/xserver/tree/miext/shadow/shadow.c?id=xorg-server-1.12.1#n136
And it also enables damage extension to track all the drawing
operations performed with the shadow buffer in order to copy the
updated areas to the real framebuffer from time to time. The update
itself happens here:
http://cgit.freedesktop.org/xorg/xserver/tree/miext/shadow/shpacked.c?id=xorg-server-1.12.1#n43
With the damage extension active, we go through damageCopyArea:
http://cgit.freedesktop.org/xorg/xserver/tree/miext/damage/damage.c?id=xorg-server-1.12.1#n801
before reaching fbCopyArea:
http://cgit.freedesktop.org/xorg/xserver/tree/fb/fbcopy.c?id=xorg-server-1.12.1#n265
While running x11perf test and doing copying/scrolling tests, the
function calls inside of X server look more or less like this:
62. [00:29:27.779] fbCopyArea()
63. [00:29:27.779] DamageReportDamage()
64. [00:29:27.783] fbCopyArea()
65. [00:29:27.783] DamageReportDamage()
66. [00:29:27.787] fbCopyArea()
67. [00:29:27.792] shadowUpdatePacked()
68. [00:29:27.792] DamageReportDamage()
69. [00:29:27.795] fbCopyArea()
70. [00:29:27.795] DamageReportDamage()
71. [00:29:27.799] fbCopyArea()
72. [00:29:27.800] DamageReportDamage()
73. [00:29:27.803] fbCopyArea()
74. [00:29:27.803] DamageReportD
Re: [RFC PATCH 00/11] OMAP System Control Module
Hello again, On Fri, May 25, 2012 at 11:25:50AM +0300, Eduardo Valentin wrote: > Hello Paul and Tony, FYI, Forgot to mention that these patches are available here: git://gitorious.org/omap-thermal/omap-thermal.git omap_scm_dev > > This is a series of patches adding a basic support for system control module, > on OMAP4+ context. It is a working in progress, but I wanted to share already > to get your feedback. > > I've modeled the driver as an MFD. You will see in this series: > . A rework of the system control module header (patch from Santosh, picked > from the list) > . Device creation for control module core > . Early device creation for control module core > . The MFD core driver for system control module > . The MFD child for usb-phy pin control > . The MFD child for bandgap sensor > . Very early exposure of OMAP4 thermal zone > . All added drivers are only supporting DT probing > . The series is based on linux-omap master, as it has the hwmod entries for > SCM. > > The overall idea of this series is to put in place the infrastructure. It is > not touching nor removing the existing APIs under mach-omap2/control.c for > now. > But the target is to have these APIs moved to the MFD core driver. > > For early access, like ID checking, I have written the platform driver > as an early platform driver and you will see also early device addition > and probing under device.c for this case. This is of course a proposal. > I see that there are people that thing this is a bit of an overkill. > Konstantin (CCd) was proposing a simpler solution by having > APIs with early_* prefixes, and solve the IO address mapping with > a DT entry, for instance. But feel free to propose better ways. > > This code has been ripped off from the Android 3.1 branch. I have rewritten > a couple of things, but the major driver functions and API's entries are kept. > > So, based on this series, I see as a TODO list, for system control core > driver: > - Start to move all the existing APIs under mach-omap2/control.c to the mfd > core. > - Rewrite the users of the existing APIs, mentioned on previous item > Once we decide the API and agree on how to deal with early calls. > - Add remaining children (from top of my head, the CAM is one of them, > but I also think we should prob have one for HWOBS for instance) > - Test on boards that use the existing APIs. > > TODO list for bandgap driver: > - Improve thermal zone definition for OMAP4 > - Introduce the thermal zones for OMAP5 > > Amit, due to hwmod dep, I didn't include any cooling binding in this series, > based on the generic CPU cooling device. > > Overall series has been tested only with panda board OMAP4460. > > Your comments are welcome. > > All best, > > Eduardo Valentin (9): > ARM: OMAP: expose control.h to mach area > OMAP: Add early device for system control module > mfd: omap: control: core system control driver > OMAP2+: use control module mfd driver in omap_type > mfd: omap: control: usb-phy: introduce the ctrl-module usb driver > ARM: OMAP4+: Adding the temperature sensor register set bit fields > ARM: OMAP4+: thermal: introduce bandgap temperature sensor > omap4: thermal: add basic CPU thermal zone > ARM: DT: Add support to system control module for OMAP4 > > Kishon Vijay Abraham I (1): > arm: omap: device: create a device for system control module > > Santosh Shilimkar (1): > ARM: OMAP4: Remove un-used control module headers and defines. > > .../devicetree/bindings/mfd/omap_control.txt | 44 + > .../devicetree/bindings/thermal/omap_bandgap.txt | 27 + > arch/arm/boot/dts/omap4.dtsi | 13 + > arch/arm/mach-omap2/Kconfig|1 + > arch/arm/mach-omap2/am35xx-emac.c |2 +- > arch/arm/mach-omap2/board-3430sdp.c|2 +- > arch/arm/mach-omap2/board-4430sdp.c|2 +- > arch/arm/mach-omap2/board-am3517crane.c|2 +- > arch/arm/mach-omap2/board-am3517evm.c |2 +- > arch/arm/mach-omap2/board-apollon.c|2 +- > arch/arm/mach-omap2/board-cm-t3517.c |2 +- > arch/arm/mach-omap2/board-h4.c |2 +- > arch/arm/mach-omap2/board-igep0020.c |2 +- > arch/arm/mach-omap2/board-ldp.c|2 +- > arch/arm/mach-omap2/board-omap3logic.c |2 +- > arch/arm/mach-omap2/board-omap4panda.c |2 +- > arch/arm/mach-omap2/board-omap4pcm049.c|2 +- > arch/arm/mach-omap2/clock2420_data.c |2 +- > arch/arm/mach-omap2/clock2430_data.c |2 +- > arch/arm/mach-omap2/clock3xxx_data.c |2 +- > arch/arm/mach-omap2/clock44xx_data.c |2 +- > arch/arm/mach-omap2/common.c |2 +- > arch/arm/mach-omap2/control.c |2 +- > arch/arm/mach-omap2/cpuidle34xx.c
[RFC PATCH 09/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor
In the System Control Module, OMAP supplies a voltage reference
and a temperature sensor feature that are gathered in the band
gap voltage and temperature sensor (VBGAPTS) module. The band
gap provides current and voltage reference for its internal
circuits and other analog IP blocks. The analog-to-digital
converter (ADC) produces an output value that is proportional
to the silicon temperature.
This patch provides a platform driver which expose this feature.
It is moduled as a MFD child of the System Control Module core
MFD driver.
This driver provides only APIs to access the device properties,
like temperature, thresholds and update rate.
Signed-off-by: Eduardo Valentin
Signed-off-by: Keerthy
---
.../devicetree/bindings/thermal/omap_bandgap.txt | 27 +
drivers/thermal/Kconfig| 13 +
drivers/thermal/Makefile |4 +-
drivers/thermal/omap-bandgap.c | 1601
drivers/thermal/omap-bandgap.h | 63 +
5 files changed, 1707 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/thermal/omap_bandgap.txt
create mode 100644 drivers/thermal/omap-bandgap.c
create mode 100644 drivers/thermal/omap-bandgap.h
diff --git a/Documentation/devicetree/bindings/thermal/omap_bandgap.txt
b/Documentation/devicetree/bindings/thermal/omap_bandgap.txt
new file mode 100644
index 000..430bcf8
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/omap_bandgap.txt
@@ -0,0 +1,27 @@
+* Texas Instrument OMAP SCM bandgap bindings
+
+In the System Control Module, OMAP supplies a voltage reference
+and a temperature sensor feature that are gathered in the band
+gap voltage and temperature sensor (VBGAPTS) module. The band
+gap provides current and voltage reference for its internal
+circuits and other analog IP blocks. The analog-to-digital
+converter (ADC) produces an output value that is proportional
+to the silicon temperature.
+
+Required properties:
+- compatible : Should be:
+ - "ti,omap4460-control-bandgap" : for OMAP4460 bandgap
+ - "ti,omap5430-control-bandgap" : for OMAP5430 bandgap
+- interrupts : this entry should indicate which interrupt line
+the talert signal is routed to;
+Specific:
+- ti,tshut-gpio : this entry should be used to inform which GPIO
+line the tshut signal is routed to;
+
+Example:
+
+bandgap {
+ compatible = "ti,omap4460-control-bandgap";
+ interrupts = <0 126 4>; /* talert */
+ ti,tshut-gpio = <86>;
+};
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 514a691..ffdd240 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -26,3 +26,16 @@ config SPEAR_THERMAL
help
Enable this to plug the SPEAr thermal sensor driver into the Linux
thermal framework
+
+config OMAP_BANDGAP
+ tristate "Texas Instruments OMAP4+ temperature sensor driver"
+ depends on THERMAL
+ depends on MFD_OMAP_CONTROL
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4460+ on die bandgap temperature sensor support. The register
+ set is part of system control module.
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
+
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index a9fff0b..5ff1af1 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -3,4 +3,6 @@
#
obj-$(CONFIG_THERMAL) += thermal_sys.o
-obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
\ No newline at end of file
+obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
+omap-thermal-y := omap-bandgap.o
diff --git a/drivers/thermal/omap-bandgap.c b/drivers/thermal/omap-bandgap.c
new file mode 100644
index 000..3d5a12b
--- /dev/null
+++ b/drivers/thermal/omap-bandgap.c
@@ -0,0 +1,1601 @@
+/*
+ * OMAP4 Bandgap temperature sensor driver
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy
+ * Author: Moiz Sonasath
+ * Couple of fixes, DT and MFD adaptation:
+ * Eduardo Valentin
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#inc
[RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap4.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d2cb392 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,18 @@
ti,hwmods = "mmc5";
ti,needs-special-reset;
};
+
+ ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = "ti,omap4-control";
+ ti,hwmods = "ctrl_module_core";
+ bandgap {
+ compatible = "ti,omap4460-bandgap";
+ interrupts = <0 126 4>; /* talert */
+ ti,tshut-gpio = <86>; /* tshut */
+ };
+ usb {
+ compatible = "ti,omap4-usb-phy";
+ };
+ };
};
};
--
1.7.7.1.488.ge8e1c
--
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
[RFC PATCH 10/11] omap4: thermal: add basic CPU thermal zone
This patch exposes OMAP4 thermal sensor as a thermal zone
named "cpu". Only thermal creation is done here.
TODO:
- Add cooling bindings
- Add extrapolation rules
Signed-off-by: Eduardo Valentin
---
drivers/thermal/Kconfig | 12 ++
drivers/thermal/Makefile|1 +
drivers/thermal/omap-bandgap.c |1 +
drivers/thermal/omap-bandgap.h | 12 ++
drivers/thermal/omap4-thermal.c | 72 +++
5 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 drivers/thermal/omap4-thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index ffdd240..2e82797 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -39,3 +39,15 @@ config OMAP_BANDGAP
This includes alert interrupts generation and also the TSHUT
support.
+config OMAP4_THERMAL
+ bool "Texas Instruments OMAP4 thermal support"
+ depends on OMAP_BANDGAP
+ depends on ARCH_OMAP4
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP4 SoC family. The current chip supported are:
+ - OMAP4460
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
+
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 5ff1af1..6397678 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
+omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
diff --git a/drivers/thermal/omap-bandgap.c b/drivers/thermal/omap-bandgap.c
index 3d5a12b..d53ffcf 100644
--- a/drivers/thermal/omap-bandgap.c
+++ b/drivers/thermal/omap-bandgap.c
@@ -1192,6 +1192,7 @@ static const struct omap_bandgap_data omap4460_data = {
.fclock_name = "bandgap_ts_fclk",
.div_ck_name = "div_ts_ck",
.conv_table = omap4460_adc_to_temp,
+ .expose_sensor = omap4_thermal_expose_sensor,
.sensors = {
{
.registers = &omap4460_mpu_temp_sensor_registers,
diff --git a/drivers/thermal/omap-bandgap.h b/drivers/thermal/omap-bandgap.h
index 12e0d6b..0f5b3e6 100644
--- a/drivers/thermal/omap-bandgap.h
+++ b/drivers/thermal/omap-bandgap.h
@@ -60,4 +60,16 @@ int omap_bandgap_write_update_interval(struct omap_bandgap
*bg_ptr, int id,
int omap_bandgap_read_temperature(struct omap_bandgap *bg_ptr, int id,
int *temperature);
+#ifdef CONFIG_OMAP4_THERMAL
+int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain);
+#else
+static inline int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr,
+ int id, char *domain)
+{
+ return 0;
+}
+
+#endif
+
#endif
diff --git a/drivers/thermal/omap4-thermal.c b/drivers/thermal/omap4-thermal.c
new file mode 100644
index 000..f83cf96
--- /dev/null
+++ b/drivers/thermal/omap4-thermal.c
@@ -0,0 +1,72 @@
+/*
+ * OMAP4 thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap-bandgap.h"
+
+struct omap4_thermal_data {
+ struct thermal_zone_device *omap4_thermal;
+ struct omap_bandgap *bg_ptr;
+ int sensor_id;
+};
+
+static inline int omap4_thermal_get_temp(struct thermal_zone_device *thermal,
+unsigned long *temp)
+{
+ struct omap4_thermal_data *data = thermal->devdata;
+ int ret, tmp;
+
+ ret = omap_bandgap_read_temperature(data->bg_ptr, data->sensor_id,
+ &tmp);
+ if (!ret)
+ *temp = tmp;
+
+ return ret;
+}
+
+static struct thermal_zone_device_ops omap4_thermal_ops = {
+ .get_temp = omap4_thermal_get_temp,
+};
+
+int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain)
+{
+ struct omap4_thermal_data *data;
+
+ data = devm_kzalloc(bg_ptr->dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(bg_ptr->dev, "kzalloc fail\n");
+ return -ENOMEM;
+ }
+ data->sensor_id = id;
+ data->bg_ptr = bg_ptr;
+ data->omap4_th
[RFC PATCH 08/11] ARM: OMAP4+: Adding the temperature sensor register set bit fields
OMAP4460 specific temperature sensor register bit fields are added. Existing OMAP4 entries are renamed to OMAP4430. Signed-off-by: Keerthy Signed-off-by: Eduardo Valentin --- arch/arm/mach-omap2/include/mach/control.h | 116 1 files changed, 116 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/control.h b/arch/arm/mach-omap2/include/mach/control.h index cf42764..171b504 100644 --- a/arch/arm/mach-omap2/include/mach/control.h +++ b/arch/arm/mach-omap2/include/mach/control.h @@ -230,6 +230,122 @@ /* OMAP44xx control McBSP padconf */ #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP 0x061c +/* TEMP_SENSOR OMAP4430 */ +#define OMAP4430_BGAP_TEMPSOFF_SHIFT 12 +#define OMAP4430_BGAP_TEMPSOFF_MASK(1 << 12) +#define OMAP4430_BGAP_TSHUT_SHIFT 11 +#define OMAP4430_BGAP_TSHUT_MASK (1 << 11) +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_MASK(1 << 10) +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_SHIFT9 +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK (1 << 9) +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 << 8) +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff << 0) + +/* TEMP_SENSOR OMAP4460 */ +#define OMAP4460_BGAP_TEMPSOFF_SHIFT 13 +#define OMAP4460_BGAP_TEMPSOFF_MASK(1 << 13) +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_SHIFT11 +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK (1 << 11) +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK(1 << 10) +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff << 0) + +/* BANDGAP_CTRL */ +#define OMAP4460_SINGLE_MODE_SHIFT 31 +#define OMAP4460_SINGLE_MODE_MASK (1 << 31) +#define OMAP4460_MASK_HOT_SHIFT1 +#define OMAP4460_MASK_HOT_MASK (1 << 1) +#define OMAP4460_MASK_COLD_SHIFT 0 +#define OMAP4460_MASK_COLD_MASK(1 << 0) + +/* BANDGAP_COUNTER */ +#define OMAP4460_COUNTER_SHIFT 0 +#define OMAP4460_COUNTER_MASK (0xff << 0) + +/* BANDGAP_THRESHOLD */ +#define OMAP4460_T_HOT_SHIFT 16 +#define OMAP4460_T_HOT_MASK(0x3ff << 16) +#define OMAP4460_T_COLD_SHIFT 0 +#define OMAP4460_T_COLD_MASK (0x3ff << 0) + +/* TSHUT_THRESHOLD */ +#define OMAP4460_TSHUT_HOT_SHIFT 16 +#define OMAP4460_TSHUT_HOT_MASK(0x3ff << 16) +#define OMAP4460_TSHUT_COLD_SHIFT 0 +#define OMAP4460_TSHUT_COLD_MASK (0x3ff << 0) + +/* BANDGAP_STATUS */ +#define OMAP4460_CLEAN_STOP_SHIFT 3 +#define OMAP4460_CLEAN_STOP_MASK (1 << 3) +#define OMAP4460_BGAP_ALERT_SHIFT 2 +#define OMAP4460_BGAP_ALERT_MASK (1 << 2) +#define OMAP4460_HOT_FLAG_SHIFT1 +#define OMAP4460_HOT_FLAG_MASK (1 << 1) +#define OMAP4460_COLD_FLAG_SHIFT 0 +#define OMAP4460_COLD_FLAG_MASK(1 << 0) + +/* TEMP_SENSOR OMAP5430 */ +#define OMAP5430_BGAP_TEMP_SENSOR_SOC_SHIFT12 +#define OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK (1 << 12) +#define OMAP5430_BGAP_TEMPSOFF_SHIFT 11 +#define OMAP5430_BGAP_TEMPSOFF_MASK(1 << 11) +#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 << 10) +#define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff << 0) + +/* BANDGAP_CTRL */ +#define OMAP5430_MASK_HOT_CORE_SHIFT 5 +#define OMAP5430_MASK_HOT_CORE_MASK(1 << 5) +#define OMAP5430_MASK_COLD_CORE_SHIFT 4 +#define OMAP5430_MASK_COLD_CORE_MASK (1 << 4) +#define OMAP5430_MASK_HOT_MM_SHIFT 3 +#define OMAP5430_MASK_HOT_MM_MASK (1 << 3) +#define OMAP5430_MASK_COLD_MM_SHIFT2 +#define OMAP5430_MASK_COLD_MM_MASK (1 << 2) +#define OMAP5430_MASK_HOT_MPU_SHIFT1 +#define OMAP5430_MASK_HOT_MPU_MASK (1 << 1) +#define OMAP5430_MASK_COLD_MPU_SHIFT 0 +#define OMAP5430_MASK_COLD_MPU_MASK(1 << 0) + +/* BANDGAP_COUNTER */ +
[RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
(p.s. the mailbox for musb in omap4 is present in system control
module)
[kis...@ti.com: wrote the original API's related to USB functions]
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
---
drivers/usb/otg/Kconfig | 13
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap4-usb-phy.c | 130 +
include/linux/usb/omap4_usb_phy.h | 53 +++
4 files changed, 197 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/omap4-usb-phy.c
create mode 100644 include/linux/usb/omap4_usb_phy.h
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..e2840f1 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,19 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP4_USB_PHY
+ tristate "Texas Instruments OMAP4+ USB pin control driver"
+ depends on MFD_OMAP_CONTROL
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4+ USB pin control driver. The register set is part of system
+ control module.
+
+ USB phy in OMAP configures control module register for powering on
+ the phy, configuring VBUSVALID, AVALID, IDDIG and SESSEND. For
+ performing the above mentioned configuration, API's are added in
+ by this children of the control module driver.
+
config NOP_USB_XCEIV
tristate "NOP USB Transceiver Driver"
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..60c8c83 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP4_USB_PHY)+= omap4-usb-phy.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap4-usb-phy.c b/drivers/usb/otg/omap4-usb-phy.c
new file mode 100644
index 000..a29ea45
--- /dev/null
+++ b/drivers/usb/otg/omap4-usb-phy.c
@@ -0,0 +1,130 @@
+/*
+ * OMAP4 system control module driver, USB control children
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Contact:
+ *Kishon Vijay Abraham I
+ *Eduardo Valentin
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * omap4_usb_phy_power - power on/off the phy using control module reg
+ * @dev: struct device *
+ * @on: 0 or 1, based on powering on or off the PHY
+ *
+ * omap_usb2 can call this API to power on or off the PHY.
+ */
+int omap4_usb_phy_power(struct device *dev, int on)
+{
+ u32 val;
+ int ret;
+
+ if (on) {
+ ret = omap_control_readl(dev, CONTROL_DEV_CONF, &val);
+ if (!ret && (val & PHY_PD)) {
+ ret = omap_control_writel(dev, ~PHY_PD,
+ CONTROL_DEV_CONF);
+ /* XXX: add proper documentation for this delay */
+ mdelay(200);
+ }
+ } else {
+ ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
+
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @dev: struct device *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), the phy should call this API
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), the phy should call
+ * this API to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * The phy should call this API, if OMAP is disconnected from host or device.
+ */
+int omap4_usb_phy_mailbox(struct device
[RFC PATCH 06/11] OMAP2+: use control module mfd driver in omap_type
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/id.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5bb9746..acfd698 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
@@ -40,8 +41,14 @@ EXPORT_SYMBOL(omap_rev);
int omap_type(void)
{
+ struct device *scm;
+ int ret = 0;
u32 val = 0;
+ scm = omap_control_get();
+ if (IS_ERR_OR_NULL(scm))
+ return 0;
+
if (cpu_is_omap24xx()) {
val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
} else if (cpu_is_am33xx()) {
@@ -49,16 +56,23 @@ int omap_type(void)
} else if (cpu_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
- val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ ret = omap_control_readl(scm, OMAP4_CTRL_MODULE_CORE_STATUS,
+&val);
} else {
pr_err("Cannot detect omap type!\n");
goto out;
}
+ if (ret) {
+ pr_err("problem while fetching omap type\n");
+ goto out;
+ }
+
val &= OMAP2_DEVICETYPE_MASK;
val >>= 8;
out:
+ omap_control_put(scm);
return val;
}
EXPORT_SYMBOL(omap_type);
--
1.7.7.1.488.ge8e1c
--
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
[RFC PATCH 05/11] mfd: omap: control: core system control driver
This patch introduces a MFD core device driver for
OMAP system control module.
The control module allows software control of
various static modes supported by the device. It is
composed of two control submodules: general control
module and device (padconfiguration) control
module.
In this patch, the children defined are for:
. USB-phy pin control
. Bangap temperature sensor
Device driver is probed with postcore_initcall.
However, as some of the APIs exposed by this driver
may be needed in very early init phase, an early init
class is also available: "early_omap_control".
Signed-off-by: J Keerthy
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
---
.../devicetree/bindings/mfd/omap_control.txt | 44
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/plat-omap/Kconfig |3 +
drivers/mfd/Kconfig|9 +
drivers/mfd/Makefile |1 +
drivers/mfd/omap-control-core.c| 211
include/linux/mfd/omap_control.h | 69 +++
7 files changed, 338 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt
create mode 100644 drivers/mfd/omap-control-core.c
create mode 100644 include/linux/mfd/omap_control.h
diff --git a/Documentation/devicetree/bindings/mfd/omap_control.txt
b/Documentation/devicetree/bindings/mfd/omap_control.txt
new file mode 100644
index 000..46d5e7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -0,0 +1,44 @@
+* Texas Instrument OMAP System Control Module (SCM) bindings
+
+The control module allows software control of various static modes supported by
+the device. The control module controls the settings of various device modules
+through register configuration and internal signals. It also controls the pad
+configuration, pin functional multiplexing, and the routing of internal signals
+(such as PRCM signals or DMA requests) to output pins configured for hardware
+observability.
+
+Required properties:
+- compatible : Should be:
+ - "ti,omap3-control" for OMAP3 support
+ - "ti,omap4-control" for OMAP4 support
+ - "ti,omap5-control" for OMAP5 support
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the control module:
+ Should be "ctrl_module_core";
+
+Sub-nodes:
+- bandgap : contains the bandgap node
+
+ The bindings details of individual bandgap device can be found in:
+ Documentation/devicetree/bindings/thermal/omap_bandgap.txt
+
+- usb : contains the usb phy pin control node
+
+ The only required property for this child is:
+- compatible = "ti,omap4-control-usb";
+
+Examples:
+
+ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = "ti,omap4-control";
+ ti,hwmods = "ctrl_module_core";
+ bandgap {
+ compatible = "ti,omap4460-bandgap";
+ interrupts = <0 126 4>; /* talert */
+ ti,tshut-gpio = <86>; /* tshut */
+ };
+ usb {
+ compatible = "ti,omap4-usb-phy";
+ };
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a2b946d..7dfe5e1 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -52,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+ select ARCH_HAS_CONTROL_MODULE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..222dbad 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,9 @@ menu "TI OMAP Common Features"
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+ bool
+
choice
prompt "OMAP System Type"
default ARCH_OMAP2PLUS
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 11e4438..25a66d8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -795,6 +795,15 @@ config MFD_WL1273_CORE
driver connects the radio-wl1273 V4L2 module and the wl1273
audio codec.
+config MFD_OMAP_CONTROL
+ bool "Texas Instruments OMAP System control module"
+ depends on ARCH_HAS_CONTROL_MODULE
+ help
+ This is the core driver for system control module. This driver
+ is responsible for creating the control module mfd child,
+ like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
+ change for off mode.
+
config MFD_OMAP_USB_HOST
bool "Support OMAP USBHS core driver"
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 05fa538..00f99d6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_V
[RFC PATCH 04/11] OMAP: Add early device for system control module
This is a way to add an early device for system control module.
the code is also requesting for driver registration and probing.
Done at early_initcall because at that time, ioremapping is possible.
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/devices.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9332673..58cc5c3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -40,6 +40,35 @@
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
+static struct resource control_resources[] = {
+ [0] = {
+ .start = 0x4a002000,
+ .end= 0x4a0027ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+static struct platform_device control_device = {
+ .name = "omap-control-core",
+ .id = 0,
+ .resource = control_resources,
+ .num_resources = ARRAY_SIZE(control_resources),
+};
+
+static struct platform_device *early_devices[] __initdata = {
+ &control_device,
+};
+
+static int __init plat_early_device_setup(void)
+{
+ early_platform_add_devices(early_devices,
+ ARRAY_SIZE(early_devices));
+ early_platform_driver_register_all("early_omap_control");
+ early_platform_driver_probe("early_omap_control", 1, false);
+
+ return 0;
+}
+early_initcall(plat_early_device_setup);
+
static int omap_init_control(void)
{
struct omap_hwmod *oh;
--
1.7.7.1.488.ge8e1c
--
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
[RFC PATCH 03/11] arm: omap: device: create a device for system control module
From: Kishon Vijay Abraham I
Extracts the device data from hwmod database and create a platform device
using omap device build.
The device build is done during postcore_initcall.
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/devices.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 152c266..9332673 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -40,6 +40,32 @@
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
+static int omap_init_control(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ const char *oh_name, *name;
+
+ oh_name = "ctrl_module_core";
+ name = "omap-control-core";
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("Could not lookup hwmod for %s\n", oh_name);
+ return PTR_ERR(oh);
+ }
+
+ pdev = omap_device_build(name, -1, oh, NULL, 0, NULL, 0, true);
+ if (IS_ERR(pdev)) {
+ pr_err("Could not build omap_device for %s %s\n",
+ name, oh_name);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
+postcore_initcall(omap_init_control);
+
static int __init omap3_l3_init(void)
{
struct omap_hwmod *oh;
--
1.7.7.1.488.ge8e1c
--
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
[RFC PATCH 02/11] ARM: OMAP: expose control.h to mach area
This patch exposes the definitions under control.h to
drivers outside the machine code.
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/am35xx-emac.c|2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/board-am3517crane.c |2 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap3logic.c |2 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-omap4pcm049.c |2 +-
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/clock44xx_data.c |2 +-
arch/arm/mach-omap2/common.c |2 +-
arch/arm/mach-omap2/control.c|2 +-
arch/arm/mach-omap2/cpuidle34xx.c|2 +-
arch/arm/mach-omap2/devices.c|2 +-
arch/arm/mach-omap2/display.c|2 +-
arch/arm/mach-omap2/hsmmc.c |2 +-
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/{ => include/mach}/control.h |2 +-
arch/arm/mach-omap2/mcbsp.c |2 +-
arch/arm/mach-omap2/mux.c|2 +-
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
arch/arm/mach-omap2/opp3xxx_data.c |2 +-
arch/arm/mach-omap2/opp4xxx_data.c |2 +-
arch/arm/mach-omap2/pm24xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 +-
arch/arm/mach-omap2/prcm.c |2 +-
arch/arm/mach-omap2/serial.c |2 +-
arch/arm/mach-omap2/sleep34xx.S |2 +-
arch/arm/mach-omap2/sr_device.c |2 +-
arch/arm/mach-omap2/usb-fs.c |2 +-
arch/arm/mach-omap2/voltage.c|2 +-
38 files changed, 38 insertions(+), 38 deletions(-)
rename arch/arm/mach-omap2/{ => include/mach}/control.h (99%)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 447682c..c3da28a 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -21,7 +21,7 @@
#include
#include
-#include "control.h"
+#include
static struct mdio_platform_data am35xx_emac_mdio_pdata;
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 37abb0d..ad1132b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -46,7 +46,7 @@
#include "sdram-qimonda-hyb18m512160af-6.h"
#include "hsmmc.h"
#include "pm.h"
-#include "control.h"
+#include
#include "common-board-devices.h"
#define CONFIG_DISABLE_HFCLK 1
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 94af6cd..8f7f76b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -47,7 +47,7 @@
#include "mux.h"
#include "hsmmc.h"
-#include "control.h"
+#include
#include "common-board-devices.h"
#define ETH_KS8851_IRQ 34
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 3b8a53c..2ad514d 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -32,7 +32,7 @@
#include "am35xx-emac.h"
#include "mux.h"
-#include "control.h"
+#include
#define GPIO_USB_POWER 35
#define GPIO_USB_NRESET38
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 99790eb..bef6586 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -41,7 +41,7 @@
#include "am35xx-emac.h"
#include "mux.h"
-#include "control.h"
+#include
#include "hsmmc.h"
#define LCD_PANEL_PWR 176
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index 768ece2..bd04fe2 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -44,7 +44,7 @@
#include
#include "mux.h"
-#include "control.h"
+#include
/* LED & Switch macros */
#define LED0_GPIO1313
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 9e66e16..1d2b7a3 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -47,7 +47,7 @@
#include
#include "mux.h"
-#inc
[RFC PATCH 00/11] OMAP System Control Module
Hello Paul and Tony,
This is a series of patches adding a basic support for system control module,
on OMAP4+ context. It is a working in progress, but I wanted to share already
to get your feedback.
I've modeled the driver as an MFD. You will see in this series:
. A rework of the system control module header (patch from Santosh, picked from
the list)
. Device creation for control module core
. Early device creation for control module core
. The MFD core driver for system control module
. The MFD child for usb-phy pin control
. The MFD child for bandgap sensor
. Very early exposure of OMAP4 thermal zone
. All added drivers are only supporting DT probing
. The series is based on linux-omap master, as it has the hwmod entries for SCM.
The overall idea of this series is to put in place the infrastructure. It is
not touching nor removing the existing APIs under mach-omap2/control.c for now.
But the target is to have these APIs moved to the MFD core driver.
For early access, like ID checking, I have written the platform driver
as an early platform driver and you will see also early device addition
and probing under device.c for this case. This is of course a proposal.
I see that there are people that thing this is a bit of an overkill.
Konstantin (CCd) was proposing a simpler solution by having
APIs with early_* prefixes, and solve the IO address mapping with
a DT entry, for instance. But feel free to propose better ways.
This code has been ripped off from the Android 3.1 branch. I have rewritten
a couple of things, but the major driver functions and API's entries are kept.
So, based on this series, I see as a TODO list, for system control core driver:
- Start to move all the existing APIs under mach-omap2/control.c to the mfd
core.
- Rewrite the users of the existing APIs, mentioned on previous item
Once we decide the API and agree on how to deal with early calls.
- Add remaining children (from top of my head, the CAM is one of them,
but I also think we should prob have one for HWOBS for instance)
- Test on boards that use the existing APIs.
TODO list for bandgap driver:
- Improve thermal zone definition for OMAP4
- Introduce the thermal zones for OMAP5
Amit, due to hwmod dep, I didn't include any cooling binding in this series,
based on the generic CPU cooling device.
Overall series has been tested only with panda board OMAP4460.
Your comments are welcome.
All best,
Eduardo Valentin (9):
ARM: OMAP: expose control.h to mach area
OMAP: Add early device for system control module
mfd: omap: control: core system control driver
OMAP2+: use control module mfd driver in omap_type
mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
ARM: OMAP4+: Adding the temperature sensor register set bit fields
ARM: OMAP4+: thermal: introduce bandgap temperature sensor
omap4: thermal: add basic CPU thermal zone
ARM: DT: Add support to system control module for OMAP4
Kishon Vijay Abraham I (1):
arm: omap: device: create a device for system control module
Santosh Shilimkar (1):
ARM: OMAP4: Remove un-used control module headers and defines.
.../devicetree/bindings/mfd/omap_control.txt | 44 +
.../devicetree/bindings/thermal/omap_bandgap.txt | 27 +
arch/arm/boot/dts/omap4.dtsi | 13 +
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/am35xx-emac.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-4430sdp.c|2 +-
arch/arm/mach-omap2/board-am3517crane.c|2 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/board-apollon.c|2 +-
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c|2 +-
arch/arm/mach-omap2/board-omap3logic.c |2 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-omap4pcm049.c|2 +-
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/clock44xx_data.c |2 +-
arch/arm/mach-omap2/common.c |2 +-
arch/arm/mach-omap2/control.c |2 +-
arch/arm/mach-omap2/cpuidle34xx.c |2 +-
arch/arm/mach-omap2/devices.c | 57 +-
arch/arm/mach-omap2/display.c |2 +-
arch/arm/mach-omap2/hsmmc.c|2 +-
arch/arm/mach-omap2/id.c | 18 +-
arch/arm/mach-omap2/{ => include/mach}/control.h | 163 ++-
.../include/mach/ctrl_module_core_44xx.h | 391 -
.../include/mach/c
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Thu, 2012-05-24 at 18:39 -0600, Paul Walmsley wrote: > cc Jean > > Hello Tomi, > > On Wed, 16 May 2012, Tomi Valkeinen wrote: > > > I also suspect that this could be just a plain DSS bug. The default FIFO > > low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the > > FIFO when there are 960 or less bytes in the fifo, and stops at 1023. > > The fifo is 1024 bytes). The values are calculated with fifo_size - > > burst_size and fifo_size - 1. > > > > We are now using FIFO merge features, which combines multiple fifos into > > one when possible, making the fifo size 1024*3 = 3072. Using the same > > low threshold and increasing the high threshold to 960/3071 works fine. > > Changing the high threshold to 3008 causes underflows. Increasing the > > low threshold to ~1600 makes DSS work again. > > Just a few thoughts. > > In terms of the high threshold, it seems really strange to me that > changing the high threshold would make such a difference. Naïvely, I'd > assume that you'd want to set it as high as possible? I suppose in cases > where the interconnect is congested, setting it lower might allow lower > latency for other interconnect users, but I'd hope we don't have to worry > much about that. So it doesn't seem to me that there would be any > advantage to setting it lower than the maximum. It's true that the high threshold should be set as high as possible, and this is what we do. Except for DSI command mode output on OMAP3, where, for unknown reason, the highest value (fifosize - 1) doesn't work and we need to program it to fifosize - burstsize. And this was causing the original problem, fifosize - burstsize was not working for other outputs properly. I guess this also hints that there's something wrong with omap3 and the dss fifo thresholds. > Probably the low threshold is the more important parameter, from a PM > perspective. If you know the FIFO's drain rate and the low threshold, it > should be possible to calculate the maximum latency that the FIFO can > tolerate to avoid an underflow. This could be used to specify a device PM > QoS constraint to prevent the interconnect latency from exceeding that > value. Yes, this is how the low threshold should be adjusted. I have never tried to calculate the threshold need, though, as I haven't had all the information and understanding to properly calculate it. > I'd guess the calculations would be something like this -- (I hope you can > correct my relative ignorance of the DSS in the following estimates): > > Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO > drain rate would be 864 x 480 x 32 bits/second. Since the FIFO width is > 32 bits, that's I think the DSS fifo entries are 8 bit on omap2/3, 128bits on omap4. At least those are the "units" used with fifo size, threshold sizes, burst size, etc. >864 x 480 = 414 780 FIFO entries/second, or > >(1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry. > > So if you need a low FIFO threshold at 960 entries, you could call the > device PM QoS functions to set a wakeup latency constraint for the > interconnect would be nothing greater than this: > >(2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs > > (The reality is that it would need to be something less than this, to > account for the time needed for the GFX DMA transfer to start supplying > data, etc.) Makes sense. Another reason for underflows we have is the different rotation engines. VRFB on omap2/3, and TILER on omap4. Both increase the "work" needed to get pixels, although I'm not sure what the actual causes for the increased work are. > The ultimate goal, with Jean's device PM QoS patches, is that these > constraints could change the DPLL autoidle settings or powerdomain states > to ensure the constraint was met. He's got a page here: > > http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement > > (Unfortunately it's not clear what the DPLL autoidle modes and voltage > scaling bits are set to for many of the estimates, and we also know that > there are many software optimizations possible for our idle path.) > > We're still working on getting the OMAP device PM QoS patches merged, but > the Linux core support is there, so you should be able to patch your > drivers to use them -- see for example dev_pm_qos_add_request(). Thanks for the pointers, I need to study that. > Just paging through the DSS TRM section, some other settings that might be > worth checking are: > > - is DISPC_GFX_ATTRIBUTES.GFXBURSTSIZE set to 16x32? Yes. (8 x 128 on omap4) I presume each DMA burst has a small overhead, so maximizing the burst size minimizes the overhead. Do you see any other effect with the burst size? I mean, do you see any need to know the burst size value when trying to calculate optimal thresholds? > - is DISPC_GFX_ATTRIBUTES.GFXFIFOPRELOAD set to 1? No. We set it to 0 so that PRELOAD is used. If I've understood right,
Re: usage of sparse or other trick for improved type safety
Hi, * Woodruff, Richard [120524 11:16]: > Hi Tony, > > I am hoping to solicit an opinion from you for OMAP frameworks in general. > > In some recent review there was some debate about how it was good practice to > form parameters in a way which didn't get misused. Nishanth was having some > experience where end users doing custom ports made some hard to find mistakes. > > I was wondering if it is useful to create a standard or it's a waste of time. > The knee-jerk reaction to comment is to consider annotations for driver > users of api's, then inside the framework trust internals to do the right > thing. Complexity divide between a driver and some frameworks might be > similar to user-vs-kernel. > > I think example in this case was IVA and other external subsystems commonly > got away using stale definitions when managing their own power domains. > Example seemed a little pedantic but it is true that this has broken several > times through migrations. At customer fan out it causes a lot of effort which > could have been avoided. > > Just last week someone was trying to caste away an iomem annotation from > external driver based on warning. For me warning was a good thing and forced > discussion. > > I do recall you pushing what ARM and Linux tress did in this area back into > OMAP years back. Question is if it's worth internalizing more for our ever > growing frameworks. I think we should have frameworks in place to manage clocks and powerdomains for pretty much all drivers using runtime PM by now. That has helped making the device drivers more generic and easier to maintain. And it's also less likely for device drivers to accidentally mess up things for other drivers. Before we had these frameworks in place it was often hard to debug when something did not work for some omaps. Things would just not work or would stop working for some drivers with no ideas what was going on. So yeah, having these kind of frameworks in place has helped a lot to avoid breakage like you're describing above. For some external subsystems it might be possible to let the omap kernel manage powerdomains and other resource via remote proc interface, assuming these registers are ioremapped in the omap kernel side and not owned by the external subsystem. The messaging to do this would add some undesired latencies though, but maybe those would not be so critical for the external subsystems as they tend to be full on or completely off type accelerators. The other alternative of course is to implement similar frameworks for the external subsystems. Some of this might be possible to implement as simple macros with some type checks if it's subsystem specific. For doing it for all omap devices, macros were soon found not to be enough as the various bits all over need to be linked together for managing various resources. 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 v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
* Paul Walmsley [120523 17:55]: > On Tue, 22 May 2012, Tony Lindgren wrote: > > > > Unfortunately for many of the older boards these values will probably > > remain unknown. > > > > So the better approach here is to just disable frequency scaling > > for these cases. Otherwise we'll be breaking old boards with smsc911x > > where the timings for the FPGA controlling smsc911x are unknown. > > > > If we somehow manage to get those values without breaking support for > > these boards, then yes I agree we should deprecate hardcoded and > > bootloader values. > > I was thinking that if we log the register values supplied by the > bootloader to the console, then someone can write a patch to the board > file or DT data to set those register values explicitly in the kernel, > once they're known. Or at least just report them to the l-o list. > > So then that should reduce the problem cases down to boards which no one > reports the data to the mailing list within a few mainline kernel releases > -- i.e., boards which are unmaintained. For those boards, I'd suggest > that we just drop GPMC support until someone shows up who has a board and > can test-boot it. Or just drop the board completely ;-) OK seems fair to me. It still allows us to boot the older boards with minimal changes (but without L3 frequency scaling). Sounds like those registers should be dumped only if no configuration is specified to avoid spamming the console. 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 0/4] omap legacy full speed usb cleanup for v3.6
* Paul Walmsley [120524 23:05]: > On Mon, 21 May 2012, Tony Lindgren wrote: > > > This series removes the old legacy fulls speed support for > > omap2 as it's pretty much only used for omap1 only. > > > > For omap2, only n8x0 seems to have active development, and > > that has the external high speed tusb chip instead. > > Just FYI, full speed host USB exists on OMAP4. It's in section 23.13 of > the TRM and we have a hwmod for it. No idea if anyone is actually using > it. Interesting, so it's back on omap4 for some legacy compability reasons i guess. It's not mentioned for omap3 at all, but maybe it's lurking around there somewhere too. Looking at the omap4 TRM, looks like there are two instances of OHCI: The HS OHCI/EHCI controller, and the legacy FS OHCI only controller. The legacy one is using separate transceiver pins (usbc1_*) from the HS OHCI/EHCI controller pins (usbb[12]_*). As the OHCI registers are standard, I'd assume it would be possible to make the FS USB instance to work with the mach-omap2/usb-host.c and drivers/usb/host/ohci-omap3.c driver. So it should still be OK to remove the code in this series. I doubt that anybody would want to use the legacy FS OHCI controller instead of the HS OHCI/EHCI controller though.. If somebody is actually using the legacy controller at usbc1_* pins, please respond. 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
