Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
On Wed, 2012-02-15 at 11:59 -0800, Kevin Hilman wrote: Cousson, Benoit b-cous...@ti.com writes: Kevin, Do we still need to set the dev.parent to omap_device_parent? Nope. I guess the default platform_bus parent is good enough and potentially the DSS children should be able to overwrite that. Yes, now that we use PM domains, we don't need it. I just sent a patch to remove omap_device_parent. But it's still not possible to create a custom parent-child hierarchy with omap_devices. Or can I change the parent of a platform_device after it has been created? (doesn't sound very clean even if I can) Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCHv2 7/8] arm: omap: clockdomain: add support for preventing domain transitions
On Wed, 2012-02-15 at 11:35 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Some clockdomains can't support manual domain transitions triggered by clock framework, and must be prevented from doing so. Added clkdm flag CLKDM_NO_MANUAL_TRANS for doing this. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Dumb Q: what's the difference between this new flag and CLKDM_CAN_SWSUP? CAN_SWSUP controls software wakeup / sleep (clktrctrl values 1 and 2), but it still allows hwsup based transitions during runtime (basically using values 0 3 for the same register.) NO_MANUAL_TRANS prevents both, but still allows hwauto mode being enabled in the first place. I was thinking about adding a flag for preventing the autodep disabling as this was the root cause for the problem I saw, but I wanted to optimize the _clkdm_clk_hwmod_enable/disable for this case, as the domain is not going through any transitions. -Tero -- 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: [PATCHv2 7/8] arm: omap: clockdomain: add support for preventing domain transitions
Tero, On Thu, Feb 16, 2012 at 2:09 PM, Tero Kristo t-kri...@ti.com wrote: On Wed, 2012-02-15 at 11:35 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Some clockdomains can't support manual domain transitions triggered by clock framework, and must be prevented from doing so. Added clkdm flag CLKDM_NO_MANUAL_TRANS for doing this. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Dumb Q: what's the difference between this new flag and CLKDM_CAN_SWSUP? CAN_SWSUP controls software wakeup / sleep (clktrctrl values 1 and 2), but it still allows hwsup based transitions during runtime (basically using values 0 3 for the same register.) NO_MANUAL_TRANS prevents both, but still allows hwauto mode being enabled in the first place. I was thinking about adding a flag for preventing the autodep disabling as this was the root cause for the problem I saw, but I wanted to optimize the _clkdm_clk_hwmod_enable/disable for this case, as the domain is not going through any transitions. Which clock-domain you are refering here which needs this flag ? Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] gpio/omap: Use devm_ API and add request_mem_region
On 2/16/2012 7:37 AM, Shubhrajyoti wrote:
On Thursday 16 February 2012 11:11 AM, DebBarma, Tarun Kanti wrote:
Hi Benoit,
On Wed, Feb 15, 2012 at 9:34 PM, Benoit Coussonb-cous...@ti.com wrote:
Replace the regular kzalloc and ioremap with the devm_ equivalent
to simplify error handling.
Add the missing devm_request_mem_region to reserve the region used
by the driver.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Tarun Kanti DebBarmatarun.ka...@ti.com
---
drivers/gpio/gpio-omap.c | 35 +++
1 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index a0c3e03..c3a9dc8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -19,7 +19,7 @@
#includelinux/err.h
#includelinux/clk.h
#includelinux/io.h
-#includelinux/slab.h
+#includelinux/device.h
#includelinux/pm_runtime.h
#includelinux/pm.h
@@ -1052,23 +1052,19 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
struct gpio_bank *bank;
int ret = 0;
- if (!dev-platform_data) {
- ret = -EINVAL;
- goto err_exit;
- }
+ if (!dev-platform_data)
+ return -EINVAL;
- bank = kzalloc(sizeof(struct gpio_bank), GFP_KERNEL);
+ bank = devm_kzalloc(pdev-dev, sizeof(struct gpio_bank), GFP_KERNEL);
if (!bank) {
dev_err(dev, Memory alloc failed\n);
- ret = -ENOMEM;
- goto err_exit;
+ return -ENOMEM;
}
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!res)) {
dev_err(dev, Invalid IRQ resource\n);
- ret = -ENODEV;
- goto err_free;
+ return -ENODEV;
How is the memory allocated to 'bank' getting freed before return -ENODEV?
I think that may not be needed
It is indeed not needed, and this is the whole point of that API
compared to the regular kzalloc... and that's why it is highly
recommended to switch to this kind of 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: [PATCHv2 8/8] arm: omap3: prevent per_clkdm from attempting manual domain transitions
On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Attempting this will cause problems especially with off-mode enabled.
Please be more verbose about the problems seen, and the root cause(s).
I was actually looking forward for some help with this commit message,
as I am still not quite sure what is going on in here. :) Here is the
log for suspend (btw, cam_pwrdm does not go to off in mainline yet, but
I think that is probably fixed by the patch from Paul,
omap_set_pwrdm_state() does not work properly.) The warning comes out
after wakeup from off-mode, and it is triggered by the disabling of
autodeps before off-mode entry.
[ 79.010345] PM: Syncing filesystems ... done.
[ 79.083801] Freezing user space processes ... (elapsed 0.01 seconds)
done.
[ 79.110839] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) don
e.
[ 79.141845] Suspending console(s) (use no_console_suspend to debug)
[ 79.266815] PM: suspend of devices complete after 115.551 msecs
[ 79.269958] PM: late suspend of devices complete after 3.142 msecs
[ 79.270050] Disabling non-boot CPUs ...
[ 79.697235] Powerdomain (cam_pwrdm) didn't enter target state 0
[ 79.697265] Could not enter target state in pm_suspend
[ 79.699829] PM: early resume of devices complete after 2.257 msecs
[ 79.699920] [ cut here ]
[ 79.699981] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:161
omap3_l3_app_ir
q+0xd8/0x130()
[ 79.699981] In-band Error seen by MPU at address 0
[ 79.699981] Modules linked in:
[ 79.700042] [c001bcd0] (unwind_backtrace+0x0/0xf4) from
[c00428d0] (warn_
slowpath_common+0x4c/0x64)
[ 79.700073] [c00428d0] (warn_slowpath_common+0x4c/0x64) from
[c004297c] (
warn_slowpath_fmt+0x30/0x40)
[ 79.700103] [c004297c] (warn_slowpath_fmt+0x30/0x40) from
[c0034a2c] (oma
p3_l3_app_irq+0xd8/0x130)
[ 79.700103] [c0034a2c] (omap3_l3_app_irq+0xd8/0x130) from
[c00a09e4] (han
dle_irq_event_percpu+0x5c/0x22c)
[ 79.700134] [c00a09e4] (handle_irq_event_percpu+0x5c/0x22c) from
[c00a0bf0
] (handle_irq_event+0x3c/0x5c)
[ 79.700164] [c00a0bf0] (handle_irq_event+0x3c/0x5c) from
[c00a3a70] (hand
le_level_irq+0xac/0x118)
[ 79.700195] [c00a3a70] (handle_level_irq+0xac/0x118) from
[c00a0490] (gen
eric_handle_irq+0x34/0x44)
[ 79.700225] [c00a0490] (generic_handle_irq+0x34/0x44) from
[c00151ec] (ha
IdRQ+0x4c/0xac)
[ 79.700256] [c00151ec] (handle_IRQ+0x4c/0xac) from [c0008548]
(omap3_intc
_handle_irq+0x44/0x4c)
[ 79.700256] [c0008548] (omap3_intc_handle_irq+0x44/0x4c) from
[c0476824]
(__irq_svc+0x44/0x60)
[ 79.700286] Exception stack(0xcefe7e78 to 0xcefe7ec0)
[ 79.700286] 7e60:
7
a93 cedb25d0
[ 79.700317] 7e80: cedb2140 6153 c0676994
c0676994 6
153
[ 79.700347] 7ea0: c0676940 000a3008 c0721d40 cefe7ec0 7a94
c04765e4 2
153
[ 79.700347] [c0476824] (__irq_svc+0x44/0x60) from [c04765e4]
(_raw_spin_u
nlock_irqrestore+0x34/0x44)
[ 79.700378] [c04765e4] (_raw_spin_unlock_irqrestore+0x34/0x44) from
[c00a5
e18] (resume_irqs+0x9c/0xbc)
[ 79.700408] [c00a5e18] (resume_irqs+0x9c/0xbc) from [c008061c]
(suspend_d
evices_and_enter+0x114/0x2d8)
[ 79.700439] [c008061c] (suspend_devices_and_enter+0x114/0x2d8) from
[c0080
91c] (enter_state+0x13c/0x184)
[ 79.700469] [c008091c] (enter_state+0x13c/0x184) from [c007f5fc]
(state_s
tore+0xd0/0x170)
[ 79.700500] [c007f5fc] (state_store+0xd0/0x170) from [c02536a8]
(kobj_att
r_store+0x18/0x1c)
[ 79.700531] [c02536a8] (kobj_attr_store+0x18/0x1c) from
[c0167a9c] (sysfs
_write_file+0xfc/0x180)
[ 79.700561] [c0167a9c] (sysfs_write_file+0xfc/0x180) from
[c0107ed4] (vfs
_write+0xb0/0x134)
[ 79.700561] [c0107ed4] (vfs_write+0xb0/0x134) from [c0108028]
(sys_write+
0x40/0x70)
[ 79.700592] [c0108028] (sys_write+0x40/0x70) from [c0014160]
(ret_fast_sy
scall+0x0/0x3c)
[ 79.700622] ---[ end trace 338e34a6f123bc2b ]---
[ 80.121765] PM: resume of devices complete after 420.012 msecs
[ 80.414886] Restarting tasks ... done.
Kevin
Previously this issue was hidden by the fact that per_clkdm never
attempted manual idle by software, as the usecounts for the clockdomain
were broken.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clockdomains3xxx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index b84e138..db31bbf 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -282,7 +282,7 @@ static struct clockdomain usbhost_clkdm = {
static struct clockdomain per_clkdm = {
.name = per_clkdm,
.pwrdm = { .name = per_pwrdm },
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_HWSUP_SWSUP |
Re: [PATCHv2 7/8] arm: omap: clockdomain: add support for preventing domain transitions
On Thu, 2012-02-16 at 14:13 +0530, Shilimkar, Santosh wrote: Tero, On Thu, Feb 16, 2012 at 2:09 PM, Tero Kristo t-kri...@ti.com wrote: On Wed, 2012-02-15 at 11:35 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Some clockdomains can't support manual domain transitions triggered by clock framework, and must be prevented from doing so. Added clkdm flag CLKDM_NO_MANUAL_TRANS for doing this. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Dumb Q: what's the difference between this new flag and CLKDM_CAN_SWSUP? CAN_SWSUP controls software wakeup / sleep (clktrctrl values 1 and 2), but it still allows hwsup based transitions during runtime (basically using values 0 3 for the same register.) NO_MANUAL_TRANS prevents both, but still allows hwauto mode being enabled in the first place. I was thinking about adding a flag for preventing the autodep disabling as this was the root cause for the problem I saw, but I wanted to optimize the _clkdm_clk_hwmod_enable/disable for this case, as the domain is not going through any transitions. Which clock-domain you are refering here which needs this flag ? per_clkdm, see patch 8 in this same set for comments. This happens with omap3. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] gpio/omap: Remove bank-id information and misc cleanup
On 2/16/2012 6:53 AM, DebBarma, Tarun Kanti wrote:
On Wed, Feb 15, 2012 at 9:34 PM, Benoit Coussonb-cous...@ti.com wrote:
The driver does not need anymore any id to identify the GPIO instance.
Remove every occurence of the bank-id inside the driver.
Remove two trailing spaces.
Add a dev variable for better readability in probe.
Remove unused variable bank-pbase.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Tarun Kanti DebBarmatarun.ka...@ti.com
Looks fine.
If needed you can add my Acked-by:
Thanks,
Benoit
--
Tarun
---
drivers/gpio/gpio-omap.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f49bd6f..a0c3e03 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -50,7 +50,6 @@ struct gpio_regs {
struct gpio_bank {
struct list_head node;
- unsigned long pbase;
void __iomem *base;
u16 irq;
u16 virtual_irq_start;
@@ -77,7 +76,6 @@ struct gpio_bank {
int stride;
u32 width;
int context_loss_count;
- u16 id;
int power_mode;
bool workaround_enabled;
@@ -155,7 +153,7 @@ static inline void _gpio_rmw(void __iomem *base, u32 reg,
u32 mask, bool set)
{
int l = __raw_readl(base + reg);
- if (set)
+ if (set)
l |= mask;
else
l= ~mask;
@@ -495,7 +493,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
unsigned long flags;
if (bank-non_wakeup_gpios gpio_bit) {
- dev_err(bank-dev,
+ dev_err(bank-dev,
Unable to modify wakeup on non-wakeup GPIO%d\n, gpio);
return -EINVAL;
}
@@ -1048,37 +1046,36 @@ static void __devinit omap_gpio_chip_init(struct
gpio_bank *bank)
static int __devinit omap_gpio_probe(struct platform_device *pdev)
{
+ struct device *dev =pdev-dev;
struct omap_gpio_platform_data *pdata;
struct resource *res;
struct gpio_bank *bank;
int ret = 0;
- if (!pdev-dev.platform_data) {
+ if (!dev-platform_data) {
ret = -EINVAL;
goto err_exit;
}
bank = kzalloc(sizeof(struct gpio_bank), GFP_KERNEL);
if (!bank) {
- dev_err(pdev-dev, Memory alloc failed for gpio_bank\n);
+ dev_err(dev, Memory alloc failed\n);
ret = -ENOMEM;
goto err_exit;
}
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!res)) {
- dev_err(pdev-dev, GPIO Bank %i Invalid IRQ resource\n,
- pdev-id);
+ dev_err(dev, Invalid IRQ resource\n);
ret = -ENODEV;
goto err_free;
}
bank-irq = res-start;
- bank-id = pdev-id;
pdata = pdev-dev.platform_data;
bank-virtual_irq_start = pdata-virtual_irq_start;
- bank-dev =pdev-dev;
+ bank-dev = dev;
bank-dbck_flag = pdata-dbck_flag;
bank-stride = pdata-bank_stride;
bank-width = pdata-bank_width;
@@ -1098,16 +1095,14 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
/* Static mapping, never released */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (unlikely(!res)) {
- dev_err(pdev-dev, GPIO Bank %i Invalid mem resource\n,
- pdev-id);
+ dev_err(dev, Invalid mem resource\n);
ret = -ENODEV;
goto err_free;
}
bank-base = ioremap(res-start, resource_size(res));
if (!bank-base) {
- dev_err(pdev-dev, Could not ioremap gpio bank%i\n,
- pdev-id);
+ dev_err(dev, Could not ioremap\n);
ret = -ENOMEM;
goto err_free;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 8/8] arm: omap3: prevent per_clkdm from attempting manual domain transitions
On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo t-kri...@ti.com wrote: On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Attempting this will cause problems especially with off-mode enabled. Please be more verbose about the problems seen, and the root cause(s). I was actually looking forward for some help with this commit message, as I am still not quite sure what is going on in here. :) Here is the log for suspend (btw, cam_pwrdm does not go to off in mainline yet, but I think that is probably fixed by the patch from Paul, omap_set_pwrdm_state() does not work properly.) The warning comes out after wakeup from off-mode, and it is triggered by the disabling of autodeps before off-mode entry. This mostly indicates that one of the per clock-domain module clock turning ON seems to be not working well with auto deps disabled. This leads to interconnect violation. if not tried already, can you put the per_clockdomain in SW_WKUP in the low power code early resume path and see if this error goes away. regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/8] OMAP4: hwmod: add EMIF hw mod data
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: From: Benoit Cousson b-cous...@ti.com One line of change log will do here. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
Hi Tony,
On Wednesday 15 February 2012 11:58 PM, Tony Lindgren wrote:
Otherwise omap_device_build() and omap_mux related functions
can't be marked as __init when twl is build as a module.
If a board is using GPIO pins or regulators configured by an
external chip, such as TWL PMIC on I2C bus, the board must
mark those MMC controllers as deferred. Additionally both
omap_hsmmc_init() and omap_hsmmc_late_init() must be called
by the board.
For MMC controllers using internal GPIO pins for card
detect and regulators the slots don't need to be marked
deferred. In this case calling omap_hsmmc_init() is sufficient.
Note that this patch does not change the behaviour for
board-4430sdp.c board-omap4panda.c. These boards wrongly
rely on the omap_hsmmc.c init function callback to configure
the PMIC GPIO interrupt lines on external chip. If the PMIC
interrupt lines are not configured during init, they will
fail.
I tested these patches on omap3 beagle and card detect seems
to be broken. See my comment below on why.
Reported-by: Russell Kingrmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/board-2430sdp.c |2
arch/arm/mach-omap2/board-3430sdp.c |5 +
arch/arm/mach-omap2/board-4430sdp.c |4 -
arch/arm/mach-omap2/board-am3517evm.c|2
arch/arm/mach-omap2/board-cm-t35.c |6 +
arch/arm/mach-omap2/board-devkit8000.c |4 +
arch/arm/mach-omap2/board-igep0020.c |7 +-
arch/arm/mach-omap2/board-ldp.c |2
arch/arm/mach-omap2/board-omap3beagle.c |4 +
arch/arm/mach-omap2/board-omap3evm.c |5 +
arch/arm/mach-omap2/board-omap3logic.c |2
arch/arm/mach-omap2/board-omap3pandora.c |6 +
arch/arm/mach-omap2/board-omap3stalker.c | 12 ++-
arch/arm/mach-omap2/board-omap3touchbook.c |4 +
arch/arm/mach-omap2/board-omap4panda.c |4 -
arch/arm/mach-omap2/board-overo.c|5 +
arch/arm/mach-omap2/board-rm680.c|2
arch/arm/mach-omap2/board-rx51-peripherals.c |2
arch/arm/mach-omap2/board-zoom-peripherals.c |6 +
arch/arm/mach-omap2/hsmmc.c | 107 +++---
arch/arm/mach-omap2/hsmmc.h | 12 ++-
21 files changed, 147 insertions(+), 56 deletions(-)
[]...
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e921e3b..60f0501 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -413,7 +413,7 @@ static struct omap2_hsmmc_info mmc[] = {
.caps = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
-
+ .deferred = true,
},
{
.mmc= 2,
@@ -422,6 +422,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ocr_mask = 0x0010, /* 3.3V */
+ .deferred = true,
},
{} /* Terminator */
};
@@ -471,7 +472,7 @@ static int cm_t35_twl_gpio_setup(struct device *dev,
unsigned gpio,
/* gpio + 0 is mmc0_cd (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
- omap2_hsmmc_init(mmc);
+ omap_hsmmc_late_init(mmc);
omap_hsmmc_late_init() in some way needs to pass on the gpio_cd
value onto the driver via platform_data which its currently not.
better still, I think we should just populate them statically in
omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
of it already.
[]...
+void omap_hsmmc_late_init(struct omap2_hsmmc_info *controllers)
+{
+ struct platform_device *pdev;
+ int res;
+
+ for (; controllers-mmc; controllers++) {
+ if (!controllers-deferred)
+ continue;
+
+ pdev = controllers-pdev;
+ if (!pdev)
+ continue;
+
+ res = omap_device_register(pdev);
+ if (res) {
+ pr_err(Could not late init MMC %s\n,
+ controllers-name);
+ continue;
+ }
+ }
+}
regards,
Rajendra
--
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 2/8] misc: ddr: add LPDDR2 data from JESD209-2
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers Signed-off-by: Aneesh V ane...@ti.com Looks good to me. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/8] misc: ddr: add LPDDR2 data from JESD209-2
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers Signed-off-by: Aneesh V ane...@ti.com Sorry.. Missed one minor comment. --- drivers/misc/Kconfig |8 ++ drivers/misc/Makefile |1 + drivers/misc/jedec_ddr_data.c | 141 + include/linux/jedec_ddr.h | 174 + 4 files changed, 324 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/jedec_ddr_data.c create mode 100644 include/linux/jedec_ddr.h [...] diff --git a/drivers/misc/jedec_ddr_data.c b/drivers/misc/jedec_ddr_data.c new file mode 100644 index 000..299c056 --- /dev/null +++ b/drivers/misc/jedec_ddr_data.c @@ -0,0 +1,141 @@ +/* + * DDR addressing details and AC timing parameters from JEDEC specs + * + * Copyright (C) 2010 Texas Instruments, Inc. Fix the year please. Should be 2012 -- 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 3/8] misc: emif: add register definitions for EMIF
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Signed-off-by: Aneesh V ane...@ti.com --- drivers/misc/emif_regs.h | 461 ++ 1 files changed, 461 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/emif_regs.h Changelog please. O.w looks fine to me. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __init
On Wed, Feb 15, 2012 at 10:28:30AM -0800, Tony Lindgren wrote: Now that omap hsmmc init is split into two functions, it's safe to mark omap_hsmmc_init and omap_mux related functions to __init. This basically reverts the following fixes for the case where TWL was compiled as a module: d5de63 (ARM: omap: preemptively fix section mismatch in omap4_sdp4430_wifi_mux_init()) Why did you include this one? This is unrelated to the TWL problems. -- 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 2/3] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
better still, I think we should just populate them statically in
omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
of it already.
I just tried this and it seems to work...
---
arch/arm/mach-omap2/board-omap3beagle.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap3beagle.c
2012-02-16 15:38:47.046933403 +0530
+++ linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c 2012-02-16
15:40:17.355349064 +0530
@@ -253,6 +253,7 @@
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.deferred = true,
},
{} /* Terminator */
--
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 v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
On 2/16/2012 9:22 AM, Tomi Valkeinen wrote:
On Wed, 2012-02-15 at 11:59 -0800, Kevin Hilman wrote:
Cousson, Benoitb-cous...@ti.com writes:
Kevin,
Do we still need to set the dev.parent to omap_device_parent?
Nope.
I guess the defaultplatform_bus parent is good enough and
potentially the DSS children should be able to overwrite that.
Yes, now that we use PM domains, we don't need it. I just sent a patch
to remove omap_device_parent.
But it's still not possible to create a custom parent-child hierarchy
with omap_devices. Or can I change the parent of a platform_device after
it has been created? (doesn't sound very clean even if I can)
Nope, it has to be done before platform_device_add.
Thanks to Ohad patch [1] that Tony has just resent, you can use the
internal omap_device API and thus will be able to change the parent
before the registration.
Benoit
[1] ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register}
--
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 1/8] OMAP4: hwmod: add EMIF hw mod data
Santosh, Thanks for the review. On Thursday 16 February 2012 03:32 PM, Santosh Shilimkar wrote: On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: From: Benoit Coussonb-cous...@ti.com One line of change log will do here. Ok. Will add. br, Aneesh -- 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 2/8] misc: ddr: add LPDDR2 data from JESD209-2
On Thursday 16 February 2012 03:37 PM, Santosh Shilimkar wrote: On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers Signed-off-by: Aneesh Vane...@ti.com Sorry.. Missed one minor comment. --- drivers/misc/Kconfig |8 ++ drivers/misc/Makefile |1 + drivers/misc/jedec_ddr_data.c | 141 + include/linux/jedec_ddr.h | 174 + 4 files changed, 324 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/jedec_ddr_data.c create mode 100644 include/linux/jedec_ddr.h [...] diff --git a/drivers/misc/jedec_ddr_data.c b/drivers/misc/jedec_ddr_data.c new file mode 100644 index 000..299c056 --- /dev/null +++ b/drivers/misc/jedec_ddr_data.c @@ -0,0 +1,141 @@ +/* + * DDR addressing details and AC timing parameters from JEDEC specs + * + * Copyright (C) 2010 Texas Instruments, Inc. Fix the year please. Should be 2012 Ok. Will do. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 0/5] arm: omap: smps regulator support
Hi, Following changes compared to previous version: - updated to work with mainline - added acked-by Samuel Ortiz to patch 4 MFD part (no changes done to that part of code since previous version) - changed min_uV parameter name from patch 4/5 to target_uV Tested with omap3 beagle: changed + measured voltages manually for vdd1 and vdd2. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 2/5] arm: omap3: voltage: fix channel configuration
OMAP3 uses the default settings for VDD1 channel, otherwise the settings will
overlap with VDD2 and attempting to modify VDD1 voltage will actually change
VDD2 voltage.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc3xxx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vc3xxx_data.c
b/arch/arm/mach-omap2/vc3xxx_data.c
index a5ec7f8f..5d8eaf3 100644
--- a/arch/arm/mach-omap2/vc3xxx_data.c
+++ b/arch/arm/mach-omap2/vc3xxx_data.c
@@ -46,6 +46,7 @@ static struct omap_vc_common omap3_vc_common = {
};
struct omap_vc_channel omap3_vc_mpu = {
+ .flags = OMAP_VC_CHANNEL_DEFAULT,
.common = omap3_vc_common,
.smps_sa_reg = OMAP3_PRM_VC_SMPS_SA_OFFSET,
.smps_volra_reg = OMAP3_PRM_VC_SMPS_VOL_RA_OFFSET,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 1/5] TEMP: arm: OMAP3: beagle rev-c4: enable OPP6
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 29 +
arch/arm/mach-omap2/opp3xxx_data.c |4
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7ffcd28..97678e5 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -484,6 +484,35 @@ static void __init beagle_opp_init(void)
return;
}
+ if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
+ struct device *mpu_dev, *iva_dev;
+
+ mpu_dev = omap_device_get_by_hwmod_name(mpu);
+ iva_dev = omap_device_get_by_hwmod_name(iva);
+
+ if (!mpu_dev || !iva_dev) {
+ pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
+ __func__, mpu_dev, iva_dev);
+ return;
+ }
+ /* Enable MPU 720MHz opp */
+ r = opp_enable(mpu_dev, 72000);
+
+ /* Enable IVA 520MHz opp */
+ r |= opp_enable(iva_dev, 52000);
+
+ if (r) {
+ pr_err(%s: failed to enable higher opp %d\n,
+ __func__, r);
+ /*
+* Cleanup - disable the higher freqs - we dont care
+* about the results
+*/
+ opp_disable(mpu_dev, 72000);
+ opp_disable(iva_dev, 52000);
+ }
+ }
+
/* Custom OPP enabled for all xM versions */
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..a0f5fe1 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -98,6 +98,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(mpu, true, 55000, OMAP3430_VDD_MPU_OPP4_UV),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6, OMAP3430_VDD_MPU_OPP5_UV),
+ /* MPU OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER(mpu, false, 72000, OMAP3430_VDD_MPU_OPP5_UV),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -123,6 +125,8 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
OPP_INITIALIZER(iva, true, 4, OMAP3430_VDD_MPU_OPP4_UV),
/* DSP OPP5 */
OPP_INITIALIZER(iva, true, 43000, OMAP3430_VDD_MPU_OPP5_UV),
+ /* DSP OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER(iva, false, 52000, OMAP3430_VDD_MPU_OPP5_UV),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 3/5] arm: omap3: add common twl configurations for vdd1 and vdd2
VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
are needed by DVFS.
Voltage ranges for VDD1 and VDD2 are taken from twl4030/twl5030 data manual.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 10b20c6..5f62e51 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -126,6 +126,38 @@ static struct regulator_init_data omap3_vpll2_idata = {
.consumer_supplies = omap3_vpll2_supplies,
};
+static struct regulator_consumer_supply omap3_vdd1_supply[] = {
+ REGULATOR_SUPPLY(vcc, mpu.0),
+};
+
+static struct regulator_consumer_supply omap3_vdd2_supply[] = {
+ REGULATOR_SUPPLY(vcc, l3_main.0),
+};
+
+static struct regulator_init_data omap3_vdd1 = {
+ .constraints = {
+ .name = VDD1,
+ .min_uV = 60,
+ .max_uV = 145,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3_vdd1_supply),
+ .consumer_supplies = omap3_vdd1_supply,
+};
+
+static struct regulator_init_data omap3_vdd2 = {
+ .constraints = {
+ .name = VDD2,
+ .min_uV = 60,
+ .max_uV = 145,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3_vdd2_supply),
+ .consumer_supplies = omap3_vdd2_supply,
+};
+
void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
u32 pdata_flags, u32 regulators_flags)
{
@@ -133,6 +165,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
pmic_data-irq_base = TWL4030_IRQ_BASE;
if (!pmic_data-irq_end)
pmic_data-irq_end = TWL4030_IRQ_END;
+ if (!pmic_data-vdd1)
+ pmic_data-vdd1 = omap3_vdd1;
+ if (!pmic_data-vdd2)
+ pmic_data-vdd2 = omap3_vdd2;
/* Common platform data configurations */
if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 5/5] arm: omap3: twl: add external controllers for core voltage regulators
VDD1 and VDD2 now use voltage processor for controlling the regulators.
This is done by passing additional voltdm data during the regulator init.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 33 +++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 5f62e51..0c453e7 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -31,12 +31,25 @@
#include twl-common.h
#include pm.h
+#include voltage.h
static struct i2c_board_info __initdata pmic_i2c_board_info = {
.addr = 0x48,
.flags = I2C_CLIENT_WAKE,
};
+static int twl_set_voltage(void *data, int target_uV)
+{
+ struct voltagedomain *voltdm = (struct voltagedomain *)data;
+ return voltdm_scale(voltdm, target_uV);
+}
+
+static int twl_get_voltage(void *data)
+{
+ struct voltagedomain *voltdm = (struct voltagedomain *)data;
+ return voltdm_get_voltage(voltdm);
+}
+
void __init omap_pmic_init(int bus, u32 clkrate,
const char *pmic_type, int pmic_irq,
struct twl4030_platform_data *pmic_data)
@@ -158,6 +171,16 @@ static struct regulator_init_data omap3_vdd2 = {
.consumer_supplies = omap3_vdd2_supply,
};
+static struct twl_regulator_driver_data omap3_vdd1_drvdata = {
+ .get_voltage = twl_get_voltage,
+ .set_voltage = twl_set_voltage,
+};
+
+static struct twl_regulator_driver_data omap3_vdd2_drvdata = {
+ .get_voltage = twl_get_voltage,
+ .set_voltage = twl_set_voltage,
+};
+
void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
u32 pdata_flags, u32 regulators_flags)
{
@@ -165,10 +188,16 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
pmic_data-irq_base = TWL4030_IRQ_BASE;
if (!pmic_data-irq_end)
pmic_data-irq_end = TWL4030_IRQ_END;
- if (!pmic_data-vdd1)
+ if (!pmic_data-vdd1) {
+ omap3_vdd1.driver_data = omap3_vdd1_drvdata;
+ omap3_vdd1_drvdata.data = voltdm_lookup(mpu_iva);
pmic_data-vdd1 = omap3_vdd1;
- if (!pmic_data-vdd2)
+ }
+ if (!pmic_data-vdd2) {
+ omap3_vdd2.driver_data = omap3_vdd2_drvdata;
+ omap3_vdd2_drvdata.data = voltdm_lookup(core);
pmic_data-vdd2 = omap3_vdd2;
+ }
/* Common platform data configurations */
if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv9 4/5] regulator: twl4030: add support for external voltage get/set
This is needed for SMPS regulators, which use the OMAP voltage
processor for voltage get/set functions instead of the normal I2C
channel. For this purpose, regulator_init_data-driver_data contents
are expanded, it is now a struct which contains function pointers
for the set/get voltage operations, a data pointer for these, and
the previously used features bitmask.
Signed-off-by: Tero Kristo t-kri...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com [for the MFD part]
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Liam Girdwood l...@ti.com
---
drivers/mfd/twl-core.c| 16 ++-
drivers/regulator/twl-regulator.c | 39
include/linux/i2c/twl.h |7 ++
3 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index e04e04d..fae5f76 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -619,6 +619,8 @@ add_regulator_linked(int num, struct regulator_init_data
*pdata,
unsigned num_consumers, unsigned long features)
{
unsigned sub_chip_id;
+ struct twl_regulator_driver_data drv_data;
+
/* regulator framework demands init_data ... */
if (!pdata)
return NULL;
@@ -628,7 +630,19 @@ add_regulator_linked(int num, struct regulator_init_data
*pdata,
pdata-num_consumer_supplies = num_consumers;
}
- pdata-driver_data = (void *)features;
+ if (pdata-driver_data) {
+ /* If we have existing drv_data, just add the flags */
+ struct twl_regulator_driver_data *tmp;
+ tmp = pdata-driver_data;
+ tmp-features |= features;
+ } else {
+ /* add new driver data struct, used only during init */
+ drv_data.features = features;
+ drv_data.set_voltage = NULL;
+ drv_data.get_voltage = NULL;
+ drv_data.data = NULL;
+ pdata-driver_data = drv_data;
+ }
/* NOTE: we currently ignore regulator IRQs, e.g. for short circuits */
sub_chip_id = twl_map[TWL_MODULE_PM_MASTER].sid;
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 181a2cf..0afc9e1a 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -58,6 +58,16 @@ struct twlreg_info {
/* chip specific features */
unsigned long features;
+
+ /*
+* optional override functions for voltage set/get
+* these are currently only used for SMPS regulators
+*/
+ int (*get_voltage)(void *data);
+ int (*set_voltage)(void *data, int target_uV);
+
+ /* data passed from board for external get/set voltage */
+ void*data;
};
@@ -522,15 +532,25 @@ twl4030smps_set_voltage(struct regulator_dev *rdev, int
min_uV, int max_uV,
struct twlreg_info *info = rdev_get_drvdata(rdev);
int vsel = DIV_ROUND_UP(min_uV - 60, 12500);
- twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE_SMPS_4030,
- vsel);
+ if (info-set_voltage) {
+ return info-set_voltage(info-data, min_uV);
+ } else {
+ twlreg_write(info, TWL_MODULE_PM_RECEIVER,
+ VREG_VOLTAGE_SMPS_4030, vsel);
+ }
+
return 0;
}
static int twl4030smps_get_voltage(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int vsel = twlreg_read(info, TWL_MODULE_PM_RECEIVER,
+ int vsel;
+
+ if (info-get_voltage)
+ return info-get_voltage(info-data);
+
+ vsel = twlreg_read(info, TWL_MODULE_PM_RECEIVER,
VREG_VOLTAGE_SMPS_4030);
return vsel * 12500 + 60;
@@ -1052,6 +1072,7 @@ static int __devinit twlreg_probe(struct platform_device
*pdev)
struct regulator_init_data *initdata;
struct regulation_constraints *c;
struct regulator_dev*rdev;
+ struct twl_regulator_driver_data*drvdata;
for (i = 0, info = NULL; i ARRAY_SIZE(twl_regs); i++) {
if (twl_regs[i].desc.id != pdev-id)
@@ -1066,8 +1087,16 @@ static int __devinit twlreg_probe(struct platform_device
*pdev)
if (!initdata)
return -EINVAL;
- /* copy the features into regulator data */
- info-features = (unsigned long)initdata-driver_data;
+ drvdata = initdata-driver_data;
+
+ if (!drvdata)
+ return -EINVAL;
+
+ /* copy the driver data into regulator data */
+ info-features = drvdata-features;
+ info-data = drvdata-data;
+ info-set_voltage = drvdata-set_voltage;
+ info-get_voltage = drvdata-get_voltage;
/* Constrain board-specific capabilities according to what
* this driver and the
Re: [RFC PATCH 3/8] misc: emif: add register definitions for EMIF
On Thursday 16 February 2012 03:40 PM, Santosh Shilimkar wrote: On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Signed-off-by: Aneesh Vane...@ti.com --- drivers/misc/emif_regs.h | 461 ++ 1 files changed, 461 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/emif_regs.h Changelog please. O.w looks fine to me. Ok. Will add. thanks, Aneesh -- 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 4/8] misc: emif: add basic infrastructure for EMIF driver
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
EMIF is an SDRAM controller used in various Texas Instruments
SoCs. EMIF supports, based on its revision, one or more of
LPDDR2/DDR2/DDR3 protocols.
Add the basic infrastructure for EMIF driver that includes
driver registration, probe, parsing of platform data etc.
Signed-off-by: Aneesh V ane...@ti.com
---
drivers/misc/Kconfig | 12 ++
drivers/misc/Makefile |1 +
drivers/misc/emif.c | 300
+
include/linux/emif.h | 160 ++
4 files changed, 473 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/emif.c
create mode 100644 include/linux/emif.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 8337bf6..d68184a 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -459,6 +459,18 @@ config DDR
information. This data is useful for drivers handling
DDR SDRAM controllers.
+config EMIF
Add TI prefix here since it's TI IP and not a generic one.
+ tristate Texas Instruments EMIF driver
+ select DDR
+ help
+ This driver is for the EMIF module available in Texas Instruments
+ SoCs. EMIF is an SDRAM controller that, based on its revision,
+ supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols.
+ This driver takes care of only LPDDR2 memories presently. The
+ functions of the driver includes re-configuring AC timing
+ parameters and other settings during frequency, voltage and
+ temperature changes
+
config ARM_CHARLCD
bool ARM Ltd. Character LCD Driver
depends on PLAT_VERSATILE
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4759166..076db0f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_C2PORT)+= c2port/
obj-$(CONFIG_IWMC3200TOP) += iwmc3200top/
obj-$(CONFIG_HMC6352)+= hmc6352.o
obj-$(CONFIG_DDR)+= jedec_ddr_data.o
+obj-$(CONFIG_EMIF) += emif.o
obj-y+= eeprom/
obj-y+= cb710/
obj-$(CONFIG_SPEAR13XX_PCIE_GADGET) += spear13xx_pcie_gadget.o
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
new file mode 100644
index 000..ba1e3f9
--- /dev/null
+++ b/drivers/misc/emif.c
@@ -0,0 +1,300 @@
+/*
+ * EMIF driver
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
Fix year. 2012
+ *
+ * Aneesh V ane...@ti.com
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/kernel.h
+#include linux/reboot.h
+#include linux/emif.h
+#include linux/io.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/slab.h
+#include linux/seq_file.h
+#include linux/module.h
+#include linux/spinlock.h
+#include emif_regs.h
+
+/**
+ * struct emif_data - Per device static data for driver's use
+ * @duplicate: Whether the DDR devices attached to
this EMIF
+ * instance are exactly same as that on EMIF1. In
+ * this case we can save some memory and processing
+ * @temperature_level: Maximum temperature of LPDDR2 devices
attached
+ * to this EMIF - read from MR4 register. If there
+ * are two devices attached to this EMIF, this
+ * value is the maximum of the two temperature
+ * levels.
+ * @irq: IRQ number
+ * @lock:lock for protecting temperature_level and
+ * associated actions from race conditions
+ * @base:base address of memory-mapped IO registers.
+ * @dev: device pointer.
+ * @addressing table with addressing information from
the spec
+ * @regs_cache: An array of 'struct emif_regs' that
stores
+ * calculated register values for different
+ * frequencies, to avoid re-calculating them on
+ * each DVFS transition.
+ * @curr_regs: The set of register values used in the
last
+ * frequency change (i.e. corresponding to the
+ * frequency in effect at the moment)
+ * @plat_data: Pointer to saved platform data.
+ */
+struct emif_data {
+ u8 duplicate;
+ u8 temperature_level;
+ u32 irq;
+ spinlock_t
Re: [RFC PATCH 5/8] misc: emif: handle frequency and voltage change events
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Change SDRAM timings and other settings as necessary on voltage and frequency changes. We calculate these register settings based on data from the device data sheet and inputs such a frequency, voltage state(stable or ramping), temperature level etc. May be you want add TBD or FIXME for notifiers when they are available. Do that in commit log as well as in the code so that we don't forget about it. Signed-off-by: Aneesh V ane...@ti.com --- Rest of the patch looks fine. -- 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 6/8] misc: emif: add interrupt and temperature handling
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
On thermal events SDRAM timing parameters are
adjusted to ensure safe operation
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Add some more details like MR4, EMIF polling frequency etc
for better understanding.
Signed-off-by: Aneesh V ane...@ti.com
---
drivers/misc/emif.c | 209
++-
1 files changed, 207 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 36ba6f4..5c2b0ae 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -500,6 +500,45 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
}
/*
+ * Get the temperature level of the EMIF instance:
+ * Reads the MR4 register of attached SDRAM parts to find out the temperature
+ * level. If there are two parts attached(one on each CS), then the
temperature
+ * level for the EMIF instance is the higher of the two temperatures.
+ */
+static void get_temperature_level(struct emif_data *emif)
+{
+ u32 temp, temperature_level;
+ unsigned long irqs;
+ void __iomem*base;
+
+ base = emif-base;
+
+ /* Read mode register 4 */
+ writel(DDR_MR4, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temperature_level = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temperature_level = (temperature_level MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+
+ if (emif-plat_data-device_info-cs1_used) {
+ writel(DDR_MR4 | CS_MASK, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temp = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temp = (temp MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+ temperature_level = max(temp, temperature_level);
+ }
+
+ spin_lock_irqsave(emif-lock, irqs);
Add a line here.
+ /* treat everything less than nominal(3) in MR4 as nominal */
+ if (unlikely(temperature_level SDRAM_TEMP_NOMINAL))
+ temperature_level = SDRAM_TEMP_NOMINAL;
+
+ /* if we get reserved value in MR4 persist with the existing value */
+ if (likely(temperature_level != SDRAM_TEMP_RESERVED_4))
+ emif-temperature_level = temperature_level;
+ spin_unlock_irqrestore(emif-lock, irqs);
+}
+
rest of the patch looks fine to me
--
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 7/8] misc: emif: add one-time settings
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Add settings that are not dependent on frequency or any other transient parameters Expand the changelog a bit. One time settings like SDRAM_CONFIG, PHY_CONTROL, TEMP alert etc. Signed-off-by: Aneesh V ane...@ti.com --- Patch looks fine. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] misc: emif: add debugfs entries for emif
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Add debug entries for: 1. calculated registers per frequency 2. last polled value of MR4(temperature level of LPDDR2 memory) Signed-off-by: Aneesh V ane...@ti.com looks good. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/8] Add TI EMIF SDRAM controller driver
Andrew, Greg, On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with DVFS. This can not be done now as DVFS support is not available yet in mainline. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. [...] arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 110 ++ drivers/misc/Kconfig | 20 + drivers/misc/Makefile |2 + drivers/misc/emif.c| 1522 drivers/misc/emif_regs.h | 461 + drivers/misc/jedec_ddr_data.c | 141 +++ include/linux/emif.h | 257 + include/linux/jedec_ddr.h | 174 Any suggestion on where this driver can reside. It's a memory controller driver which supports standard DDR functionality as per JDEC specs including thermal alert. On top of that it does support DVFS using the TI PRCM IP block. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: board-generic: Remove un-needed .atag_offset for DT_MACHINE
On 2/15/2012 7:13 PM, Tony Lindgren wrote:
* Cousson, Benoitb-cous...@ti.com [120215 04:43]:
On 2/14/2012 8:52 PM, Tony Lindgren wrote:
* Benoit Coussonb-cous...@ti.com [120213 07:59]:
Some .atag_offset entries were wrongly added during a merge conflict
resolution in 3.3.
Remove them all, since DT boot does not use that attribute anymore.
Replace as well the #if... by #ifdef for consistency.
How about let's also remove the 0x from the serial@0x.. in the .dts
files in this clean-up patch?
In the same patch?
I'm fine with fixing that as well, but since this is not in the same
file / directory, I'd rather do a different patch.
I'll do the fix anyway, it is up to you for the proper location.
OK separate patch is fine with me.
Please find the patch below, I'll include it in the branch for the pull request.
Thanks,
Benoit
---
From edc05cc7396228f21d169dd34f1871464f0a00b8 Mon Sep 17 00:00:00 2001
From: Benoit Cousson b-cous...@ti.com
Date: Thu, 16 Feb 2012 11:55:27 +0100
Subject: [PATCH] arm/dts: OMAP34: Remove the '0x' prefix for serial nodes
Follow the DTS convention and thus name the nodes name@address without
any '0x' prefix in the physical address.
Suggested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/omap3.dtsi |8
arch/arm/boot/dts/omap4.dtsi |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 216c331..1c9d10a 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -67,25 +67,25 @@
#interrupt-cells = 1;
};
- uart1: serial@0x4806a000 {
+ uart1: serial@4806a000 {
compatible = ti,omap3-uart;
ti,hwmods = uart1;
clock-frequency = 4800;
};
- uart2: serial@0x4806c000 {
+ uart2: serial@4806c000 {
compatible = ti,omap3-uart;
ti,hwmods = uart2;
clock-frequency = 4800;
};
- uart3: serial@0x4902 {
+ uart3: serial@4902 {
compatible = ti,omap3-uart;
ti,hwmods = uart3;
clock-frequency = 4800;
};
- uart4: serial@0x49042000 {
+ uart4: serial@49042000 {
compatible = ti,omap3-uart;
ti,hwmods = uart4;
clock-frequency = 4800;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index e8fe75f..f40af04 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -104,25 +104,25 @@
0x48240100 0x0100;
};
- uart1: serial@0x4806a000 {
+ uart1: serial@4806a000 {
compatible = ti,omap4-uart;
ti,hwmods = uart1;
clock-frequency = 4800;
};
- uart2: serial@0x4806c000 {
+ uart2: serial@4806c000 {
compatible = ti,omap4-uart;
ti,hwmods = uart2;
clock-frequency = 4800;
};
- uart3: serial@0x4802 {
+ uart3: serial@4802 {
compatible = ti,omap4-uart;
ti,hwmods = uart3;
clock-frequency = 4800;
};
- uart4: serial@0x4806e000 {
+ uart4: serial@4806e000 {
compatible = ti,omap4-uart;
ti,hwmods = uart4;
clock-frequency = 4800;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/8] misc: ddr: add LPDDR2 data from JESD209-2
On Thu, 16 Feb 2012 15:57:57 +0530 Aneesh V ane...@ti.com wrote: On Thursday 16 February 2012 03:37 PM, Santosh Shilimkar wrote: On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers I don't think it belongs in drivers/misc. It's not a driver but a library. lib/ might be a better place for it perhaps ? Alan -- 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 4/8] misc: emif: add basic infrastructure for EMIF driver
On Thursday 16 February 2012 04:03 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
EMIF is an SDRAM controller used in various Texas Instruments
SoCs. EMIF supports, based on its revision, one or more of
LPDDR2/DDR2/DDR3 protocols.
Add the basic infrastructure for EMIF driver that includes
driver registration, probe, parsing of platform data etc.
Signed-off-by: Aneesh Vane...@ti.com
---
drivers/misc/Kconfig | 12 ++
drivers/misc/Makefile |1 +
drivers/misc/emif.c | 300 +
include/linux/emif.h | 160 ++
4 files changed, 473 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/emif.c
create mode 100644 include/linux/emif.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 8337bf6..d68184a 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -459,6 +459,18 @@ config DDR
information. This data is useful for drivers handling
DDR SDRAM controllers.
+config EMIF
Add TI prefix here since it's TI IP and not a generic one.
Ok.
+ tristate Texas Instruments EMIF driver
+ select DDR
+ help
+ This driver is for the EMIF module available in Texas Instruments
+ SoCs. EMIF is an SDRAM controller that, based on its revision,
+ supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols.
+ This driver takes care of only LPDDR2 memories presently. The
+ functions of the driver includes re-configuring AC timing
+ parameters and other settings during frequency, voltage and
+ temperature changes
+
config ARM_CHARLCD
bool ARM Ltd. Character LCD Driver
depends on PLAT_VERSATILE
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4759166..076db0f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_C2PORT) += c2port/
obj-$(CONFIG_IWMC3200TOP) += iwmc3200top/
obj-$(CONFIG_HMC6352) += hmc6352.o
obj-$(CONFIG_DDR) += jedec_ddr_data.o
+obj-$(CONFIG_EMIF) += emif.o
obj-y += eeprom/
obj-y += cb710/
obj-$(CONFIG_SPEAR13XX_PCIE_GADGET) += spear13xx_pcie_gadget.o
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
new file mode 100644
index 000..ba1e3f9
--- /dev/null
+++ b/drivers/misc/emif.c
@@ -0,0 +1,300 @@
+/*
+ * EMIF driver
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
Fix year. 2012
+ *
+ * Aneesh Vane...@ti.com
+ * Santosh Shilimkarsantosh.shilim...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#includelinux/kernel.h
+#includelinux/reboot.h
+#includelinux/emif.h
+#includelinux/io.h
+#includelinux/device.h
+#includelinux/platform_device.h
+#includelinux/interrupt.h
+#includelinux/slab.h
+#includelinux/seq_file.h
+#includelinux/module.h
+#includelinux/spinlock.h
+#include emif_regs.h
+
+/**
+ * struct emif_data - Per device static data for driver's use
+ * @duplicate: Whether the DDR devices attached to this EMIF
+ * instance are exactly same as that on EMIF1. In
+ * this case we can save some memory and processing
+ * @temperature_level: Maximum temperature of LPDDR2 devices attached
+ * to this EMIF - read from MR4 register. If there
+ * are two devices attached to this EMIF, this
+ * value is the maximum of the two temperature
+ * levels.
+ * @irq: IRQ number
+ * @lock: lock for protecting temperature_level and
+ * associated actions from race conditions
+ * @base: base address of memory-mapped IO registers.
+ * @dev: device pointer.
+ * @addressing table with addressing information from the spec
+ * @regs_cache:An array of 'struct emif_regs' that
stores
+ * calculated register values for different
+ * frequencies, to avoid re-calculating them on
+ * each DVFS transition.
+ * @curr_regs: The set of register values used in the last
+ * frequency change (i.e. corresponding to the
+ * frequency in effect at the moment)
+ * @plat_data: Pointer to saved platform data.
+ */
+struct emif_data {
+ u8 duplicate;
+ u8 temperature_level;
+ u32 irq;
+ spinlock_t lock; /* lock to prevent
Re: [RFC PATCH 5/8] misc: emif: handle frequency and voltage change events
On Thursday 16 February 2012 04:08 PM, Santosh Shilimkar wrote: On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Change SDRAM timings and other settings as necessary on voltage and frequency changes. We calculate these register settings based on data from the device data sheet and inputs such a frequency, voltage state(stable or ramping), temperature level etc. May be you want add TBD or FIXME for notifiers when they are available. Do that in commit log as well as in the code so that we don't forget about it. Will do. Signed-off-by: Aneesh Vane...@ti.com --- Rest of the patch looks fine. -- 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 2/8] misc: ddr: add LPDDR2 data from JESD209-2
On Thu, Feb 16, 2012 at 4:40 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Thu, 16 Feb 2012 15:57:57 +0530 Aneesh V ane...@ti.com wrote: On Thursday 16 February 2012 03:37 PM, Santosh Shilimkar wrote: On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers I don't think it belongs in drivers/misc. It's not a driver but a library. lib/ might be a better place for it perhaps ? Agree for the JDEC data part. We can move this JDEC data to lib/ Thanks for the input. Any suggestion on the controller driver ? Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c: fix missing handling of errata I2C_OMAP3_1P153
Hi , On Tue, Feb 14, 2012 at 3:45 PM, Tasslehoff Kjappfot tasskj...@gmail.com wrote: Sorry about the bad mails. First time I use git send-email to follow up on a patch, and it seems I need to read up a bit more on it. Anyway. This patch is tested on our custom board based on Beagleboard rev C3. thanks for the testing . may be include it in the changelogs . Just a suggestion not an objection to the patch. From 7c1e2c14bccb16c20dc7d93088b12ac6e6e351a3 Mon Sep 17 00:00:00 2001 From: Tasslehoff Kjappfot tasskj...@gmail.com Date: Mon, 6 Feb 2012 14:14:23 +0100 Subject: [PATCH] i2c: fix missing handling of errata I2C_OMAP3_1P153 i2c_prope Nitpick : probe set the dev-errata flag, but omap_i2c_init cleared the flag again. Move the errata handling to i2c_probe. Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 801df60..d609ae2 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -468,11 +468,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1058,6 +1053,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430) dev-errata |= I2C_OMAP3_1P153; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 6/8] misc: emif: add interrupt and temperature handling
On Thursday 16 February 2012 04:11 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
On thermal events SDRAM timing parameters are
adjusted to ensure safe operation
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Add some more details like MR4, EMIF polling frequency etc
for better understanding.
Will do.
Signed-off-by: Aneesh Vane...@ti.com
---
drivers/misc/emif.c | 209 ++-
1 files changed, 207 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 36ba6f4..5c2b0ae 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -500,6 +500,45 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
}
/*
+ * Get the temperature level of the EMIF instance:
+ * Reads the MR4 register of attached SDRAM parts to find out the temperature
+ * level. If there are two parts attached(one on each CS), then the temperature
+ * level for the EMIF instance is the higher of the two temperatures.
+ */
+static void get_temperature_level(struct emif_data *emif)
+{
+ u32 temp, temperature_level;
+ unsigned long irqs;
+ void __iomem*base;
+
+ base = emif-base;
+
+ /* Read mode register 4 */
+ writel(DDR_MR4, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temperature_level = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temperature_level = (temperature_level MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+
+ if (emif-plat_data-device_info-cs1_used) {
+ writel(DDR_MR4 | CS_MASK, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temp = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temp = (temp MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+ temperature_level = max(temp, temperature_level);
+ }
+
+ spin_lock_irqsave(emif-lock, irqs);
Add a line here.
Will do.
+ /* treat everything less than nominal(3) in MR4 as nominal */
+ if (unlikely(temperature_level SDRAM_TEMP_NOMINAL))
+ temperature_level = SDRAM_TEMP_NOMINAL;
+
+ /* if we get reserved value in MR4 persist with the existing value */
+ if (likely(temperature_level != SDRAM_TEMP_RESERVED_4))
+ emif-temperature_level = temperature_level;
+ spin_unlock_irqrestore(emif-lock, irqs);
+}
+
rest of the patch looks fine to me
Thanks,
Aneesh
--
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 2/8] misc: ddr: add LPDDR2 data from JESD209-2
On Thursday 16 February 2012 04:40 PM, Alan Cox wrote: On Thu, 16 Feb 2012 15:57:57 +0530 Aneesh Vane...@ti.com wrote: On Thursday 16 February 2012 03:37 PM, Santosh Shilimkar wrote: On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: add LPDDR2 data from the JEDEC spec JESD209-2. The data includes: 1. Addressing information for LPDDR2 memories of different densities and types(S2/S4) 2. AC timing data. This data will useful for memory controller device drivers I don't think it belongs in drivers/misc. It's not a driver but a library. lib/ might be a better place for it perhaps ? Agree. I shall move it to lib/ br, Aneesh -- 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 7/8] misc: emif: add one-time settings
On Thursday 16 February 2012 04:14 PM, Santosh Shilimkar wrote: On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Add settings that are not dependent on frequency or any other transient parameters Expand the changelog a bit. One time settings like SDRAM_CONFIG, PHY_CONTROL, TEMP alert etc. Will do. Signed-off-by: Aneesh Vane...@ti.com --- Patch looks fine. Thanks, Aneesh -- 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/3] omap hsmmc init cleanup and section warning fixes for v3.4 merge window
One more patch is needed to sort out the remaining issue with
omap4 that has yet another luck based initialization for the
same issue..
I did this patch on top of your series which should fix the
issue on all omap4 boards too. Tested on omap4panda and
omap4sdp boards.
From 5a4bbd64fd1e791b922b76ea8f12dac4216c0a0f Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Thu, 16 Feb 2012 17:24:13 +0530
Subject: [PATCH] ARM: OMAP2+: Fix sequencing issues with
omap4_twl6030_hsmmc_late_init
omap4_twl6030_hsmmc_late_init() relies on twl initialization
to happen before the mmc device is probed, which seems to work
today just by luck. Now that we have support for deferred
mmc init using omap_hsmmc_late_init(), make omap4_twl6030_hsmmc_late_init()
to be called only after twl initialization and use omap_hsmmc_late_init()
for deferred mmc init.
This also fixes mmc card detect on omap4panda, which seems to be broken
as card_detect_irq was never passed from omap4panda board file.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 39 +---
arch/arm/mach-omap2/board-omap4panda.c | 44 ++--
arch/arm/mach-omap2/hsmmc.c|7 +
drivers/mfd/twl-core.c |7 +
include/linux/i2c/twl.h|1 +
5 files changed, 30 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ece9e3a..966ea8d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -407,6 +407,7 @@ static struct omap2_hsmmc_info mmc[] = {
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .deferred = true,
},
{
.mmc= 5,
@@ -455,46 +456,19 @@ static struct platform_device omap_vwlan_device = {
},
};
-static int omap4_twl6030_hsmmc_late_init(struct device *dev)
+static int omap4_twl6030_hsmmc_late_init(void)
{
int ret = 0;
- struct platform_device *pdev = container_of(dev,
- struct platform_device, dev);
- struct omap_mmc_platform_data *pdata = dev-platform_data;
-
- /* Setting MMC1 Card detect Irq */
- if (pdev-id == 0) {
- ret = twl6030_mmc_card_detect_config();
- if (ret)
- pr_err(Failed configuring MMC1 card detect\n);
- pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
- MMCDETECT_INTR_OFFSET;
- pdata-slots[0].card_detect = twl6030_mmc_card_detect;
- }
+ ret = twl6030_mmc_card_detect_config();
+ if (ret)
+ pr_err(Failed configuring MMC1 card detect\n);
+ omap_hsmmc_late_init(mmc);
return ret;
}
-static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
-{
- struct omap_mmc_platform_data *pdata;
-
- /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
- if (!dev) {
- pr_err(Failed %s\n, __func__);
- return;
- }
- pdata = dev-platform_data;
- pdata-init = omap4_twl6030_hsmmc_late_init;
-}
-
static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
*controllers)
{
- struct omap2_hsmmc_info *c;
-
omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++)
- omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
-
return 0;
}
@@ -583,6 +557,7 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_VCXIO |
TWL_COMMON_REGULATOR_VUSB |
TWL_COMMON_REGULATOR_CLK32KG);
+ sdp4430_twldata.setup = omap4_twl6030_hsmmc_late_init;
omap4_pmic_init(twl6030, sdp4430_twldata);
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 7ca7a5c..493aa0a 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -155,6 +155,7 @@ static struct omap2_hsmmc_info mmc[] = {
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
.gpio_cd= -EINVAL,
+ .deferred = true,
},
{
.name = wl1271,
@@ -204,51 +205,21 @@ struct wl12xx_platform_data omap_panda_wlan_data
__initdata = {
.board_ref_clock = 2,
};
-static int omap4_twl6030_hsmmc_late_init(struct device *dev)
+static int omap4_twl6030_hsmmc_late_init(void)
{
int ret = 0;
- struct platform_device *pdev = container_of(dev,
-
Re: [PATCH 0/3] omap hsmmc init cleanup and section warning fixes for v3.4 merge window
On Thu, Feb 16, 2012 at 05:30:59PM +0530, Nayak, Rajendra wrote: One more patch is needed to sort out the remaining issue with omap4 that has yet another luck based initialization for the same issue.. I did this patch on top of your series which should fix the issue on all omap4 boards too. Tested on omap4panda and omap4sdp boards. Can you test something with these patches? 1. Build the gpio-twl4030.c as a module, but with HSMMC support built in 2. Boot on the 4430SDP 3. Load the gpio-twl4030 module 4. Remove the gpio-twl4030 module 5. Re-load the gpio-twl4030.ko module and report back what you get. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omap hsmmc init cleanup and section warning fixes for v3.4 merge window
On Thursday 16 February 2012 05:42 PM, Russell King - ARM Linux wrote: On Thu, Feb 16, 2012 at 05:30:59PM +0530, Nayak, Rajendra wrote: One more patch is needed to sort out the remaining issue with omap4 that has yet another luck based initialization for the same issue.. I did this patch on top of your series which should fix the issue on all omap4 boards too. Tested on omap4panda and omap4sdp boards. Can you test something with these patches? 1. Build the gpio-twl4030.c as a module, but with HSMMC support built in 2. Boot on the 4430SDP twl4030 gpio is used for card detect on OMAP3, so I tried this on my Beagle instead of 4430SDP. The kernel boots up but does not detect/enumerate the mmc card. 3. Load the gpio-twl4030 module I was expecting this to now detect the card, but I instead got this error which seems to tell gpio-twl4030 has problems when built/used as a module, outside of the mmc issues. # insmod gpio-twl4030.ko [ 16.217864] twl4030_gpio twl4030_gpio: can't dispatch IRQs from modules [ 16.242004] gpiochip_add: registered GPIOs 192 to 211 on device: twl4030 4. Remove the gpio-twl4030 module 5. Re-load the gpio-twl4030.ko module and report back what you get. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omap hsmmc init cleanup and section warning fixes for v3.4 merge window
On Thursday 16 February 2012 06:04 PM, Rajendra Nayak wrote: Can you test something with these patches? 1. Build the gpio-twl4030.c as a module, but with HSMMC support built in 2. Boot on the 4430SDP twl4030 gpio is used for card detect on OMAP3, so I tried this on my Beagle instead of 4430SDP. The kernel boots up but does not detect/enumerate the mmc card. 3. Load the gpio-twl4030 module I was expecting this to now detect the card, but I instead got this error which seems to tell gpio-twl4030 has problems when built/used as a module, outside of the mmc issues. Looks like I was mislead with the errors and though the twl4030 gpio probe was bailing out with errors, which its not. It does seem to go ahead, does a mmc late init which registers the mmc omap_device and hence does a platform_device_add, but the device never seem to get probed. mmc driver is built in and registered. # insmod gpio-twl4030.ko [ 16.217864] twl4030_gpio twl4030_gpio: can't dispatch IRQs from modules [ 16.242004] gpiochip_add: registered GPIOs 192 to 211 on device: twl4030 4. Remove the gpio-twl4030 module 5. Re-load the gpio-twl4030.ko module and report back what you get. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 8/8] arm: omap3: prevent per_clkdm from attempting manual domain transitions
On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote: On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo t-kri...@ti.com wrote: On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Attempting this will cause problems especially with off-mode enabled. Please be more verbose about the problems seen, and the root cause(s). I was actually looking forward for some help with this commit message, as I am still not quite sure what is going on in here. :) Here is the log for suspend (btw, cam_pwrdm does not go to off in mainline yet, but I think that is probably fixed by the patch from Paul, omap_set_pwrdm_state() does not work properly.) The warning comes out after wakeup from off-mode, and it is triggered by the disabling of autodeps before off-mode entry. This mostly indicates that one of the per clock-domain module clock turning ON seems to be not working well with auto deps disabled. This leads to interconnect violation. if not tried already, can you put the per_clockdomain in SW_WKUP in the low power code early resume path and see if this error goes away. This seems to get rid of the dump also. It looks like some driver resume is not behaving nicely, I am trying to pinpoint the culprit currently and see whether it can provide more info. -Tero -- 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/3] omap hsmmc init cleanup and section warning fixes for v3.4 merge window
On Thu, Feb 16, 2012 at 06:45:50PM +0530, Rajendra Nayak wrote: On Thursday 16 February 2012 06:04 PM, Rajendra Nayak wrote: Can you test something with these patches? 1. Build the gpio-twl4030.c as a module, but with HSMMC support built in 2. Boot on the 4430SDP twl4030 gpio is used for card detect on OMAP3, so I tried this on my Beagle instead of 4430SDP. The kernel boots up but does not detect/enumerate the mmc card. 3. Load the gpio-twl4030 module I was expecting this to now detect the card, but I instead got this error which seems to tell gpio-twl4030 has problems when built/used as a module, outside of the mmc issues. Looks like I was mislead with the errors and though the twl4030 gpio probe was bailing out with errors, which its not. It does seem to go ahead, does a mmc late init which registers the mmc omap_device and hence does a platform_device_add, but the device never seem to get probed. mmc driver is built in and registered. # insmod gpio-twl4030.ko [ 16.217864] twl4030_gpio twl4030_gpio: can't dispatch IRQs from modules [ 16.242004] gpiochip_add: registered GPIOs 192 to 211 on device: twl4030 4. Remove the gpio-twl4030 module 5. Re-load the gpio-twl4030.ko module and report back what you get. Thanks. (4) and (5) are the key bits of what I was asking you to do. -- 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] arch/arm/plat-omap/clock.c: included linux/debugfs.h twice
arch/arm/plat-omap/clock.c: included 'linux/debugfs.h' twice, remove the duplicate. Signed-off-by: Danny Kukawka danny.kuka...@bisect.de --- arch/arm/plat-omap/clock.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index 567e4b5..56b6f8b 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c @@ -20,7 +20,6 @@ #include linux/clk.h #include linux/mutex.h #include linux/cpufreq.h -#include linux/debugfs.h #include linux/io.h #include plat/clock.h -- 1.7.8.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] arch/arm/mach-omap2/: included some headers twice
arch/arm/mach-omap2/: included some headers tiwce: - arch/arm/mach-omap2/board-ldp.c: 'linux/gpio.h' - arch/arm/mach-omap2/io.c: 'common.h' - arch/arm/mach-omap2/omap_hwmod_44xx_data.c: 'plat/i2c.h' Remove the duplicates. Signed-off-by: Danny Kukawka danny.kuka...@bisect.de --- arch/arm/mach-omap2/board-ldp.c|1 - arch/arm/mach-omap2/io.c |1 - arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 - 3 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c index 2d2a61f..ac42ebe 100644 --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@ -27,7 +27,6 @@ #include linux/io.h #include linux/smsc911x.h #include linux/mmc/host.h -#include linux/gpio.h #include mach/hardware.h #include asm/mach-types.h diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index eb50c29..9bd07f3 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -43,7 +43,6 @@ #include clockdomain.h #include plat/omap_hwmod.h #include plat/multi.h -#include common.h /* * The machine specific code may provide the extra mapping besides the diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index ef0524c..acb561e 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -28,7 +28,6 @@ #include plat/mcspi.h #include plat/mcbsp.h #include plat/mmc.h -#include plat/i2c.h #include plat/dmtimer.h #include plat/common.h -- 1.7.8.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: [PATCHv2 8/8] arm: omap3: prevent per_clkdm from attempting manual domain transitions
On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Attempting this will cause problems especially with off-mode enabled.
Please be more verbose about the problems seen, and the root cause(s).
I was actually looking forward for some help with this commit message,
as I am still not quite sure what is going on in here. :) Here is the
log for suspend (btw, cam_pwrdm does not go to off in mainline yet, but
I think that is probably fixed by the patch from Paul,
omap_set_pwrdm_state() does not work properly.) The warning comes out
after wakeup from off-mode, and it is triggered by the disabling of
autodeps before off-mode entry.
This mostly indicates that one of the per clock-domain module
clock turning ON seems to be not working well with auto deps
disabled. This leads to interconnect violation.
if not tried already, can you put the per_clockdomain in SW_WKUP
in the low power code early resume path and see if this
error goes away.
This seems to get rid of the dump also. It looks like some driver resume
is not behaving nicely, I am trying to pinpoint the culprit currently
and see whether it can provide more info.
Okay, I have some more info about this now.
What happens is that when entering off-mode, PER domain remains OFF even
during the execution of the exit phase from omap_sram_idle. Adding a
manual SW_WKUP it comes up and there are no issues. If autodeps are
enabled on the domain, it comes back from off mode as active.
Looking further in the code, we have this at the end of omap_sram_idle:
if (per_next_state PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
omap2_gpio_resume_after_idle();
wake_per();
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
}
... which seems to assume that per domain is on. Gpio code does not
control any clocks currently, as it only requires the interface clock to
be on, and as this is autoidled
Any comments how we should handle this? Shall we just keep these two
patches for handling this or add some different hackery for the gpio
issue?
-Tero
--
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: [PATCHv2 8/8] arm: omap3: prevent per_clkdm from attempting manual domain transitions
On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Attempting this will cause problems especially with off-mode enabled.
Please be more verbose about the problems seen, and the root cause(s).
I was actually looking forward for some help with this commit message,
as I am still not quite sure what is going on in here. :) Here is the
log for suspend (btw, cam_pwrdm does not go to off in mainline yet, but
I think that is probably fixed by the patch from Paul,
omap_set_pwrdm_state() does not work properly.) The warning comes out
after wakeup from off-mode, and it is triggered by the disabling of
autodeps before off-mode entry.
This mostly indicates that one of the per clock-domain module
clock turning ON seems to be not working well with auto deps
disabled. This leads to interconnect violation.
if not tried already, can you put the per_clockdomain in SW_WKUP
in the low power code early resume path and see if this
error goes away.
This seems to get rid of the dump also. It looks like some driver resume
is not behaving nicely, I am trying to pinpoint the culprit currently
and see whether it can provide more info.
Okay, I have some more info about this now.
What happens is that when entering off-mode, PER domain remains OFF even
during the execution of the exit phase from omap_sram_idle. Adding a
manual SW_WKUP it comes up and there are no issues. If autodeps are
enabled on the domain, it comes back from off mode as active.
Looking further in the code, we have this at the end of omap_sram_idle:
if (per_next_state PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
omap2_gpio_resume_after_idle();
wake_per();
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
}
... which seems to assume that per domain is on. Gpio code does not
control any clocks currently, as it only requires the interface clock to
be on, and as this is autoidled
Any comments how we should handle this? Shall we just keep these two
patches for handling this or add some different hackery for the gpio
issue?
Good. I thought too that issue will disappear.
The issue is pretty clear. Technically every driver pm_runtime() code should
be able to manage a clock-clockdomain-power domain power up/down
sequence. That should work without auto deps.
Do you narrowed down which driver resume is creating the dump ?
UART , GPIO ?
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP watchdog broken on 37XX?
did you try twl4030_wdt instead of omap_wdt? Hi Enrico, Last night I went searching around for a fix on the same watchdog problem Steve was having, but this time on a BeagleBoard XM Rev. C., using the 37xx chip. Using the twl4030_wdt driver instead of omap_wdt driver succeeded in rebooting the system, but with these issues: 1. When running the watchdog from a C program (e.g. using the example code from http://embeddedfreak.wordpress.com/2010/08/23/howto-use-linux-watchdog/), the program executable itself has been changed such that its 0 bytes after the reboot. 2. It's impossible to get the cause of the last power cycle via the watchdog. i.e. The WDIOC_GETBOOTSTATUS is handled differently in twl4030_wdt vs. omap_wdt, the latter of which relies on omap_prcm_get_reset_sources(). So while the twl4030_wdt driver gets me 90% there, I still need the ability to detect a watchdog-causes reset vs. any other reset. So, is there a patch coming for the omap_wdt driver for 37xx boards? 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: [RFC PATCH 0/8] Add TI EMIF SDRAM controller driver
On Thu, Feb 16, 2012 at 04:21:11PM +0530, Santosh Shilimkar wrote: Andrew, Greg, On Saturday 04 February 2012 05:46 PM, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with DVFS. This can not be done now as DVFS support is not available yet in mainline. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. [...] arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 110 ++ drivers/misc/Kconfig | 20 + drivers/misc/Makefile |2 + drivers/misc/emif.c| 1522 drivers/misc/emif_regs.h | 461 + drivers/misc/jedec_ddr_data.c | 141 +++ include/linux/emif.h | 257 + include/linux/jedec_ddr.h | 174 Any suggestion on where this driver can reside. It's a memory controller driver which supports standard DDR functionality as per JDEC specs including thermal alert. On top of that it does support DVFS using the TI PRCM IP block. I don't know what any of those TLA words mean, so I really can't suggest where this code should go. But just from this diffstat, it looks like you are creating a new user/kernel interface, without documenting it anywhere, which isn't ok. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 4/5] regulator: twl4030: add support for external voltage get/set
On Thu, Feb 16, 2012 at 12:27:52PM +0200, Tero Kristo wrote: This is needed for SMPS regulators, which use the OMAP voltage processor for voltage get/set functions instead of the normal I2C channel. For this purpose, regulator_init_data-driver_data contents are expanded, it is now a struct which contains function pointers for the set/get voltage operations, a data pointer for these, and the previously used features bitmask. Applied, thanks. signature.asc Description: Digital signature
Re: [RFC PATCH 4/8] misc: emif: add basic infrastructure for EMIF driver
Hi Aneesh,
On 2/4/2012 1:16 PM, Aneesh V wrote:
EMIF is an SDRAM controller used in various Texas Instruments
SoCs. EMIF supports, based on its revision, one or more of
LPDDR2/DDR2/DDR3 protocols.
Add the basic infrastructure for EMIF driver that includes
driver registration, probe, parsing of platform data etc.
Signed-off-by: Aneesh Vane...@ti.com
---
drivers/misc/Kconfig | 12 ++
drivers/misc/Makefile |1 +
drivers/misc/emif.c | 300
+
include/linux/emif.h | 160 ++
4 files changed, 473 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/emif.c
create mode 100644 include/linux/emif.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 8337bf6..d68184a 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -459,6 +459,18 @@ config DDR
information. This data is useful for drivers handling
DDR SDRAM controllers.
+config EMIF
+ tristate Texas Instruments EMIF driver
+ select DDR
+ help
+ This driver is for the EMIF module available in Texas Instruments
+ SoCs. EMIF is an SDRAM controller that, based on its revision,
+ supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols.
+ This driver takes care of only LPDDR2 memories presently. The
+ functions of the driver includes re-configuring AC timing
+ parameters and other settings during frequency, voltage and
+ temperature changes
+
config ARM_CHARLCD
bool ARM Ltd. Character LCD Driver
depends on PLAT_VERSATILE
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4759166..076db0f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_C2PORT)+= c2port/
obj-$(CONFIG_IWMC3200TOP) += iwmc3200top/
obj-$(CONFIG_HMC6352) += hmc6352.o
obj-$(CONFIG_DDR) += jedec_ddr_data.o
+obj-$(CONFIG_EMIF) += emif.o
obj-y += eeprom/
obj-y += cb710/
obj-$(CONFIG_SPEAR13XX_PCIE_GADGET) += spear13xx_pcie_gadget.o
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
new file mode 100644
index 000..ba1e3f9
--- /dev/null
+++ b/drivers/misc/emif.c
@@ -0,0 +1,300 @@
+/*
+ * EMIF driver
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
Nit: 2012?
+ *
+ * Aneesh Vane...@ti.com
+ * Santosh Shilimkarsantosh.shilim...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#includelinux/kernel.h
+#includelinux/reboot.h
+#includelinux/emif.h
+#includelinux/io.h
+#includelinux/device.h
+#includelinux/platform_device.h
+#includelinux/interrupt.h
+#includelinux/slab.h
+#includelinux/seq_file.h
+#includelinux/module.h
+#includelinux/spinlock.h
+#include emif_regs.h
+
+/**
+ * struct emif_data - Per device static data for driver's use
+ * @duplicate: Whether the DDR devices attached to
this EMIF
+ * instance are exactly same as that on EMIF1. In
+ * this case we can save some memory and processing
+ * @temperature_level: Maximum temperature of LPDDR2 devices
attached
+ * to this EMIF - read from MR4 register. If there
+ * are two devices attached to this EMIF, this
+ * value is the maximum of the two temperature
+ * levels.
+ * @irq: IRQ number
Do you really need to store the IRQ number?
+ * @lock:lock for protecting temperature_level and
+ * associated actions from race conditions
+ * @base:base address of memory-mapped IO registers.
+ * @dev: device pointer.
+ * @addressing table with addressing information from
the spec
+ * @regs_cache: An array of 'struct emif_regs' that
stores
+ * calculated register values for different
+ * frequencies, to avoid re-calculating them on
+ * each DVFS transition.
+ * @curr_regs: The set of register values used in the
last
+ * frequency change (i.e. corresponding to the
+ * frequency in effect at the moment)
+ * @plat_data: Pointer to saved platform data.
+ */
+struct emif_data {
+ u8 duplicate;
+ u8 temperature_level;
+ u32 irq;
+ spinlock_t lock; /* lock to prevent
Re: [PATCH 2/3] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
* Rajendra Nayak rna...@ti.com [120216 01:42]:
On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
better still, I think we should just populate them statically in
omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
of it already.
I just tried this and it seems to work...
---
arch/arm/mach-omap2/board-omap3beagle.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap3beagle.c
2012-02-16 15:38:47.046933403 +0530
+++ linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c 2012-02-16
15:40:17.355349064 +0530
@@ -253,6 +253,7 @@
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.deferred = true,
},
{} /* Terminator */
Would be nice to avoid the hard coded gpio numbering for the
external chips though..
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 3/3] ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __init
* Russell King - ARM Linux li...@arm.linux.org.uk [120216 01:40]: On Wed, Feb 15, 2012 at 10:28:30AM -0800, Tony Lindgren wrote: Now that omap hsmmc init is split into two functions, it's safe to mark omap_hsmmc_init and omap_mux related functions to __init. This basically reverts the following fixes for the case where TWL was compiled as a module: d5de63 (ARM: omap: preemptively fix section mismatch in omap4_sdp4430_wifi_mux_init()) Why did you include this one? This is unrelated to the TWL problems. Oops sorry, thanks for noticing. Your patch makes it __init, I was reading the patch wrong way around. Your patch should stay and my patch now changes it the wrong way. 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 2/3] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
* Tony Lindgren t...@atomide.com [120215 09:57]:
+void omap_hsmmc_late_init(struct omap2_hsmmc_info *controllers)
+{
+ struct platform_device *pdev;
+ int res;
+
+ for (; controllers-mmc; controllers++) {
+ if (!controllers-deferred)
+ continue;
+
+ pdev = controllers-pdev;
+ if (!pdev)
+ continue;
+
+ res = omap_device_register(pdev);
+ if (res) {
+ pr_err(Could not late init MMC %s\n,
+controllers-name);
+ continue;
+ }
+ }
+}
Most likely there's no need to pass struct omap2_hsmmc_info *controllers
to omap_hsmmc_late_init() here. And I'll also take a look at making
it a completion to make it more generic across various PMICs.
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 2/3] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
On 2/16/2012 5:35 PM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [120216 01:42]:
On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
better still, I think we should just populate them statically in
omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
of it already.
I just tried this and it seems to work...
---
arch/arm/mach-omap2/board-omap3beagle.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap3beagle.c
2012-02-16 15:38:47.046933403 +0530
+++ linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c 2012-02-16
15:40:17.355349064 +0530
@@ -253,6 +253,7 @@
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.deferred = true,
},
{} /* Terminator */
Would be nice to avoid the hard coded gpio numbering for the
external chips though..
DT will fix that properly, but I think that any non-DT approach will
anyway be hacky and require centralized hard coded global GPIO number
like it is done for the IRQ so far.
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: [PATCHv2 8/8] arm: omap3: prevent per_clkdm from attempting manual domain transitions
On Thu, 2012-02-16 at 21:15 +0530, Shilimkar, Santosh wrote:
On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Attempting this will cause problems especially with off-mode
enabled.
Please be more verbose about the problems seen, and the root cause(s).
I was actually looking forward for some help with this commit message,
as I am still not quite sure what is going on in here. :) Here is the
log for suspend (btw, cam_pwrdm does not go to off in mainline yet, but
I think that is probably fixed by the patch from Paul,
omap_set_pwrdm_state() does not work properly.) The warning comes out
after wakeup from off-mode, and it is triggered by the disabling of
autodeps before off-mode entry.
This mostly indicates that one of the per clock-domain module
clock turning ON seems to be not working well with auto deps
disabled. This leads to interconnect violation.
if not tried already, can you put the per_clockdomain in SW_WKUP
in the low power code early resume path and see if this
error goes away.
This seems to get rid of the dump also. It looks like some driver resume
is not behaving nicely, I am trying to pinpoint the culprit currently
and see whether it can provide more info.
Okay, I have some more info about this now.
What happens is that when entering off-mode, PER domain remains OFF even
during the execution of the exit phase from omap_sram_idle. Adding a
manual SW_WKUP it comes up and there are no issues. If autodeps are
enabled on the domain, it comes back from off mode as active.
Looking further in the code, we have this at the end of omap_sram_idle:
if (per_next_state PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
omap2_gpio_resume_after_idle();
wake_per();
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
}
... which seems to assume that per domain is on. Gpio code does not
control any clocks currently, as it only requires the interface clock to
be on, and as this is autoidled
Any comments how we should handle this? Shall we just keep these two
patches for handling this or add some different hackery for the gpio
issue?
Good. I thought too that issue will disappear.
The issue is pretty clear. Technically every driver pm_runtime() code should
be able to manage a clock-clockdomain-power domain power up/down
sequence. That should work without auto deps.
Do you narrowed down which driver resume is creating the dump ?
UART , GPIO ?
It is the gpio base stuff called from omap_sram_idle(), basically the
restore context part. If I force enable per domain before the code
snippet before, there is no dump, but if it is done after, I get the
dump.
The thing is that gpio driver doesn't currently have this kind of
mechanism for the restore context part, at least not on omap3 due to
above clocking issue (only autoidled interface clock is used.)
-Tero
--
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 2/3] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
On Thursday 16 February 2012 10:05 PM, Tony Lindgren wrote:
On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
better still, I think we should just populate them statically in
omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
of it already.
I just tried this and it seems to work...
---
arch/arm/mach-omap2/board-omap3beagle.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap3beagle.c
2012-02-16 15:38:47.046933403 +0530
+++ linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c 2012-02-16
15:40:17.355349064 +0530
@@ -253,6 +253,7 @@
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.deferred = true,
},
{} /* Terminator */
Would be nice to avoid the hard coded gpio numbering for the
external chips though..
But if you look closely, thats exactly how its handled today.
All board files hardcode gpio_base to OMAP_MAX_GPIO_LINES in
twl4030_gpio_platform_data. And thats what gets passed back
when the driver calls pdata-setup() from within probe.
--
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 2/3] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
* Rajendra Nayak rna...@ti.com [120216 08:19]:
On Thursday 16 February 2012 10:05 PM, Tony Lindgren wrote:
On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
better still, I think we should just populate them statically in
omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
of it already.
I just tried this and it seems to work...
---
arch/arm/mach-omap2/board-omap3beagle.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap3beagle.c
2012-02-16 15:38:47.046933403 +0530
+++ linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c 2012-02-16
15:40:17.355349064 +0530
@@ -253,6 +253,7 @@
.mmc= 1,
.caps = MMC_CAP_4_BIT_DATA |
MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
+ .gpio_cd= OMAP_MAX_GPIO_LINES + 0,
.deferred = true,
},
{} /* Terminator */
Would be nice to avoid the hard coded gpio numbering for the
external chips though..
But if you look closely, thats exactly how its handled today.
All board files hardcode gpio_base to OMAP_MAX_GPIO_LINES in
twl4030_gpio_platform_data. And thats what gets passed back
when the driver calls pdata-setup() from within probe.
Hmm that's not necessarily safe to do as you might have multiple
external GPIO connected, such as a PMIC and FPGA..
Anyways, it seems OK to me for now, as the DT solves that issue
properly and I don't think we currently have any boards with
multiple external GPIO chips.
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 6/6] arm: omap: pm-debug: enhanced usecount debug support
On Wed, Feb 15, 2012 at 09:20, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: On Tue, 2012-02-14 at 15:52 -0800, Tony Lindgren wrote: * Kevin Hilman khil...@ti.com [120214 14:28]: Tony Lindgren t...@atomide.com writes: * Tero Kristo t-kri...@ti.com [120214 08:19]: Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to their own file, 'usecount'. This file shows the usecounts for every active domain and their children recursively. 'count' file now only shows power state counts for powerdomains. This patch also provices a way to do printk dumps from kernel code, by calling the pm_dbg_dump_X functions. The plan is to call these functions once an error condition is detected, e.g. failed suspend. Why don't you replace this all with a userspace tool that deciphers the registers for you? This patch isn't deciphering registers, it's just dumping usecounts, and I think that is extremely useful to have in debugfs. I've already removed all the register dumping from the kernel in the hopes that someone will write a userspace tool for that. OK good to hear you're already considering it. Yes, register dumps are gone, and I am actually one of the persons who is missing it. I think there should still be some capability to get register snapshots from certain points during kernel execution, this is useful for debugging purposes. I don't know if it would be possible to do a call_usermodehelper() or something from kernel space just before wfi to read all (or part of) the PRCM registers, store them somewhere, and then decipher this data later with another tool. Any comments to this? You should look into the omapconf tool (TI internal only currently) This tool already has the ability to use /dev/mem to read/decipher OMAP PM related registers. IMO, the one thing we're still missing is the ability to take register snapshots (like immediately before and after WFI) and somehow feed those to omapconf for deciphering. Something like this perhaps? https://github.com/nmenon/linux-omap-ti-pm/commit/3cd1994fc0df9a8e3e0be74ec3f3add3ff3aef95 Regards, Nishanth Menon -- 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: [PATCHv2 8/8] arm: omap3: prevent per_clkdm from attempting manual domain transitions
Tero Kristo t-kri...@ti.com writes:
On Thu, 2012-02-16 at 21:15 +0530, Shilimkar, Santosh wrote:
On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo t-kri...@ti.com wrote:
On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote:
On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote:
On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Attempting this will cause problems especially with off-mode
enabled.
Please be more verbose about the problems seen, and the root
cause(s).
I was actually looking forward for some help with this commit message,
as I am still not quite sure what is going on in here. :) Here is the
log for suspend (btw, cam_pwrdm does not go to off in mainline yet,
but
I think that is probably fixed by the patch from Paul,
omap_set_pwrdm_state() does not work properly.) The warning comes out
after wakeup from off-mode, and it is triggered by the disabling of
autodeps before off-mode entry.
This mostly indicates that one of the per clock-domain module
clock turning ON seems to be not working well with auto deps
disabled. This leads to interconnect violation.
if not tried already, can you put the per_clockdomain in SW_WKUP
in the low power code early resume path and see if this
error goes away.
This seems to get rid of the dump also. It looks like some driver resume
is not behaving nicely, I am trying to pinpoint the culprit currently
and see whether it can provide more info.
Okay, I have some more info about this now.
What happens is that when entering off-mode, PER domain remains OFF even
during the execution of the exit phase from omap_sram_idle. Adding a
manual SW_WKUP it comes up and there are no issues. If autodeps are
enabled on the domain, it comes back from off mode as active.
Looking further in the code, we have this at the end of omap_sram_idle:
if (per_next_state PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
omap2_gpio_resume_after_idle();
wake_per();
if (per_prev_state == PWRDM_POWER_OFF)
omap3_per_restore_context();
}
... which seems to assume that per domain is on. Gpio code does not
control any clocks currently, as it only requires the interface clock to
be on, and as this is autoidled
Any comments how we should handle this? Shall we just keep these two
patches for handling this or add some different hackery for the gpio
issue?
Good. I thought too that issue will disappear.
The issue is pretty clear. Technically every driver pm_runtime() code should
be able to manage a clock-clockdomain-power domain power up/down
sequence. That should work without auto deps.
Do you narrowed down which driver resume is creating the dump ?
UART , GPIO ?
It is the gpio base stuff called from omap_sram_idle(), basically the
restore context part. If I force enable per domain before the code
snippet before, there is no dump, but if it is done after, I get the
dump.
The thing is that gpio driver doesn't currently have this kind of
mechanism for the restore context part, at least not on omap3 due to
above clocking issue (only autoidled interface clock is used.)
I'm not sure if it fully addresses this, but Tarun's series converts
GPIO to runtime PM.
Can you try with Tarun's series. See the for_3.4/gpio_cleanup_fixes_v9
branch here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] arm: omap: pm-debug: enhanced usecount debug support
Menon, Nishanth n...@ti.com writes: On Wed, Feb 15, 2012 at 09:20, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: On Tue, 2012-02-14 at 15:52 -0800, Tony Lindgren wrote: * Kevin Hilman khil...@ti.com [120214 14:28]: Tony Lindgren t...@atomide.com writes: * Tero Kristo t-kri...@ti.com [120214 08:19]: Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to their own file, 'usecount'. This file shows the usecounts for every active domain and their children recursively. 'count' file now only shows power state counts for powerdomains. This patch also provices a way to do printk dumps from kernel code, by calling the pm_dbg_dump_X functions. The plan is to call these functions once an error condition is detected, e.g. failed suspend. Why don't you replace this all with a userspace tool that deciphers the registers for you? This patch isn't deciphering registers, it's just dumping usecounts, and I think that is extremely useful to have in debugfs. I've already removed all the register dumping from the kernel in the hopes that someone will write a userspace tool for that. OK good to hear you're already considering it. Yes, register dumps are gone, and I am actually one of the persons who is missing it. I think there should still be some capability to get register snapshots from certain points during kernel execution, this is useful for debugging purposes. I don't know if it would be possible to do a call_usermodehelper() or something from kernel space just before wfi to read all (or part of) the PRCM registers, store them somewhere, and then decipher this data later with another tool. Any comments to this? You should look into the omapconf tool (TI internal only currently) This tool already has the ability to use /dev/mem to read/decipher OMAP PM related registers. IMO, the one thing we're still missing is the ability to take register snapshots (like immediately before and after WFI) and somehow feed those to omapconf for deciphering. Something like this perhaps? https://github.com/nmenon/linux-omap-ti-pm/commit/3cd1994fc0df9a8e3e0be74ec3f3add3ff3aef95 Yes, although that is targetted pretty narrowly at suspend and only PRM registers. Do you then use omapconf to display the results? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: omap_device: Replace dev_warn by dev_dbg in omap_device_build_from_dt
Benoit Cousson b-cous...@ti.com writes:
This warning becomes a little bit too verbose with the increase of
device nodes in some DTS files.
Change it to debug only.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 80d5e4c..125de17 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -343,7 +343,7 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
oh_cnt = of_property_count_strings(node, ti,hwmods);
if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
- dev_warn(pdev-dev, No 'hwmods' to build omap_device\n);
+ dev_dbg(pdev-dev, No 'hwmods' to build omap_device\n);
return -ENODEV;
}
--
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 6/6] arm: omap: pm-debug: enhanced usecount debug support
On Thu, Feb 16, 2012 at 11:35, Kevin Hilman khil...@ti.com wrote: IMO, the one thing we're still missing is the ability to take register snapshots (like immediately before and after WFI) and somehow feed those to omapconf for deciphering. Something like this perhaps? https://github.com/nmenon/linux-omap-ti-pm/commit/3cd1994fc0df9a8e3e0be74ec3f3add3ff3aef95 Yes, although that is targetted pretty narrowly at suspend and only PRM registers. Do you then use omapconf to display the results? on the platform we worked on, not everyone had access to omapconf, it was just 'cat' to take the dump. omapconf support makes sense if this is a consistent interface cross OMAP variants, even better if a similar framework is available cross SoCs. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 3/5] arm: omap3: add common twl configurations for vdd1 and vdd2
On Thu, Feb 16, 2012 at 04:27, Tero Kristo t-kri...@ti.com wrote:
VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
are needed by DVFS.
Voltage ranges for VDD1 and VDD2 are taken from twl4030/twl5030 data manual.
Please provide documentation version referenced, else we will loose
track of details at a later point of time.
Also should we rename VDD1 with vdd_mpu_iva and VDD2 as vdd_core to be readable?
Regards,
Nishanth Menon
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index 10b20c6..5f62e51 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -126,6 +126,38 @@ static struct regulator_init_data omap3_vpll2_idata = {
.consumer_supplies = omap3_vpll2_supplies,
};
+static struct regulator_consumer_supply omap3_vdd1_supply[] = {
+ REGULATOR_SUPPLY(vcc, mpu.0),
+};
+
+static struct regulator_consumer_supply omap3_vdd2_supply[] = {
+ REGULATOR_SUPPLY(vcc, l3_main.0),
+};
+
+static struct regulator_init_data omap3_vdd1 = {
+ .constraints = {
+ .name = VDD1,
+ .min_uV = 60,
+ .max_uV = 145,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3_vdd1_supply),
+ .consumer_supplies = omap3_vdd1_supply,
+};
+
+static struct regulator_init_data omap3_vdd2 = {
+ .constraints = {
+ .name = VDD2,
+ .min_uV = 60,
+ .max_uV = 145,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3_vdd2_supply),
+ .consumer_supplies = omap3_vdd2_supply,
+};
+
void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
u32 pdata_flags, u32 regulators_flags)
{
@@ -133,6 +165,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
pmic_data-irq_base = TWL4030_IRQ_BASE;
if (!pmic_data-irq_end)
pmic_data-irq_end = TWL4030_IRQ_END;
+ if (!pmic_data-vdd1)
+ pmic_data-vdd1 = omap3_vdd1;
+ if (!pmic_data-vdd2)
+ pmic_data-vdd2 = omap3_vdd2;
/* Common platform data configurations */
if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
--
1.7.4.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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
SMP local timers and their CPUfreq notifiers setup on OMAP3
Hi Santosh, Using v3.3-rc3 and building an OMAP2+ kernel I noticed that CPUfreq transitions fault because of the TWD cpufreq notifiers being called even on OMAP3. Of course, the TWD doesn't exist on OMAP3, but the TWD init is still setting up notifiers. I tried just adding a !cpu_is_omap44xx() check in local_timer_setup(), but that didn't do it, so there's more timer init that needs to be fixed up. Can you have a look at this? It's easy to reproduce by just manually triggering a frequency change with the userspace governor. Here's what I did on my 3430/n900: # cd /sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies # echo 25 scaling_setspeed [ 13.785797] Unable to handle kernel paging request at virtual address 007e900 [ 13.793426] pgd = cdc2 [ 13.796295] [007e9000] *pgd= [ 13.800079] Internal error: Oops: 5 [#1] SMP [ 13.804595] Modules linked in: [ 13.807830] CPU: 0Not tainted (3.3.0-rc3-pm+debug+initramfs #9) [ 13.814544] PC is at twd_update_frequency+0x34/0x48 [ 13.819671] LR is at twd_update_frequency+0x10/0x48 [ 13.824829] pc : [c001382c]lr : [c0013808]psr: 6093 [ 13.824829] sp : ce311dd8 ip : fp : [ 13.836914] r10: r9 : 0001 r8 : ce31 [ 13.842437] r7 : c0440458 r6 : c00137f8 r5 : r4 : c0947a74 [ 13.849304] r3 : r2 : 007e9000 r1 : r0 : [ 13.856201] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment usr [ 13.863800] Control: 10c5387d Table: 8dc20019 DAC: 0015 [ 13.869842] Process sh (pid: 599, stack limit = 0xce3102f8) [ 13.875732] Stack: (0xce311dd8 to 0xce312000) [ 13.880310] 1dc0: 6000c [ 13.888946] 1de0: 0001 0002 0 [ 13.897583] 1e00: c093d8f0 ce311ebc 0001 0001 ce310 [ 13.906188] 1e20: c001386c c0437c4c c0e95b60 c0e95ba8 0001 c0e95bf8 4 [ 13.914825] 1e40: c005ef74 ce31 c0435cf0 ce311ebc 0 [ 13.923431] 1e60: ce352b40 0007a120 c08d5108 c08ba040 c08ba040 c005f030 0 [ 13.932067] 1e80: c08bc554 c032fe2c 0007a120 c08d4b64 ce352b40 c08d8618 8 [ 13.940673] 1ea0: c08ba040 c033364c ce311ecc c0433b50 0002 ffea c0330 [ 13.949310] 1ec0: 0007a120 0007a120 2201 ce357 [ 13.957946] 1ee0: ce3d6000 cdc2aed8 ce352ba0 c0470164 0002 c032f47c 00034 [ 13.966552] 1f00: c0331cac ce352b40 0007 c032f6d0 ce352bbc 0003d090 c0930 [ 13.975189] 1f20: c093d8bc c03306a4 0007 ce311f80 0007 cdc2aec0 ce358 [ 13.983795] 1f40: ce8d20c0 0007 b6fe5000 ce311f80 0007 ce31 c [ 13.992431] 1f60: c000de74 ce987400 ce8d20c0 b6fe5000 c [ 14.001037] 1f80: 001fbac8 0007 001fbac8 4 [ 14.009674] 1fa0: c000df04 c000dd60 0007 001fbac8 0001 b6fe5000 0 [ 14.018280] 1fc0: 0007 001fbac8 0007 0004 b6fe5000 00202 [ 14.026916] 1fe0: beb565f8 00101ffc 8e8c 6010 0001 0 [ 14.035552] [c001382c] (twd_update_frequency+0x34/0x48) from [c008ac4c] ) [ 14.046478] [c008ac4c] (smp_call_function_single+0x17c/0x1c8) from [c0013) [ 14.057586] [c0013890] (twd_cpufreq_transition+0x24/0x30) from [c0437c4c) [ 14.068054] [c0437c4c] (notifier_call_chain+0x44/0x84) from [c005efe4] () [ 14.078887] [c005efe4] (__srcu_notifier_call_chain+0x70/0xa4) from [c005f) [ 14.090179] [c005f030] (srcu_notifier_call_chain+0x18/0x20) from [c032fe2) [ 14.101470] [c032fe2c] (cpufreq_notify_transition+0xc8/0x1b0) from [c0333) [ 14.111755] [c033364c] (omap_target+0x1b4/0x28c) from [c032f47c] (__cpuf) [ 14.121765] [c032f47c] (__cpufreq_driver_target+0x50/0x64) from [c0331d24) [ 14.131561] [c0331d24] (cpufreq_set+0x78/0x98) from [c032f6d0] (store_sc) [ 14.141296] [c032f6d0] (store_scaling_setspeed+0x5c/0x74) from [c03306a4) [ 14.150482] [c03306a4] (store+0x58/0x74) from [c014d868] (sysfs_write_fi) [ 14.159118] [c014d868] (sysfs_write_file+0x80/0xb4) from [c00f2c2c] (vfs) [ 14.168212] [c00f2c2c] (vfs_write+0xa8/0x138) from [c00f2e9c] (sys_write) [ 14.17] [c00f2e9c] (sys_write+0x40/0x6c) from [c000dd60] (ret_fast_s) [ 14.185577] Code: e594300c e792210c e1a01000 e5840004 (e7930002) [ 14.192169] ---[ end trace 5da3b5167c1ecdda ]--- -- 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
[PATCH v2] cpufreq: OMAP driver depends CPUfreq tables
From: Russell King rmk+ker...@arm.linux.org.uk The OMAP driver depends on CPUfreq table support for creating a table of frequencies from the OPP layer. Ensure that it's build to avoid link-time errors. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk [khil...@ti.com: make user-selectable, but default y] Tested-by: Kevin Hilman khil...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com --- This version changes the new Kconfig option to be user-selectable, but keeps the default value to be y whenever ARCH_OMAP2PLUS is enabled. I've also tested this one with various Kconfig options. drivers/cpufreq/Kconfig.arm |5 + drivers/cpufreq/Makefile|2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index e0664fe..82f1aa9 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -2,6 +2,11 @@ # ARM CPU Frequency scaling drivers # +config ARM_OMAP2PLUS_CPUFREQ + bool TI OMAP2+ + default ARCH_OMAP2PLUS + select CPU_FREQ_TABLE + config ARM_S3C64XX_CPUFREQ bool Samsung S3C64XX depends on CPU_S3C6410 diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index ac000fa..fda94c7 100644 --- a/drivers/cpufreq/Makefile +++ b/drivers/cpufreq/Makefile @@ -44,7 +44,7 @@ obj-$(CONFIG_ARM_S3C64XX_CPUFREQ) += s3c64xx-cpufreq.o obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o -obj-$(CONFIG_ARCH_OMAP2PLUS)+= omap-cpufreq.o +obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o ## # PowerPC platform drivers -- 1.7.9 -- 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] OMAP3: Add Corscience Tricorder board
Hello Tony,
do you have any comments on this?
Thomas
On 02/01/2012 04:59 PM, Thomas Weber wrote:
Tricorder is a board which is very similar to the Devkit8000.
It is designed as a base platform for further medical devices.
www.corscience.de/en/medical-engineering/products/multiparameter/mp10-board.html
Signed-off-by: Thomas Weberwe...@corscience.de
---
arch/arm/mach-omap2/Kconfig |6 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-tricorder.c| 379 ++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
sound/soc/omap/Kconfig |2 +-
sound/soc/omap/omap3beagle.c |6 +-
6 files changed, 392 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-tricorder.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41e6612..980c11c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -159,6 +159,12 @@ config MACH_DEVKIT8000
default y
select OMAP_PACKAGE_CUS
+config MACH_TRICORDER
+ bool Tricorder board
+ depends on ARCH_OMAP3
+ default y
+ select OMAP_PACKAGE_CUS
+
config MACH_OMAP_LDP
bool OMAP3 LDP board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fc9b238..83e8156 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -204,6 +204,7 @@ obj-$(CONFIG_MACH_OVERO)+= board-overo.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o
+obj-$(CONFIG_MACH_TRICORDER) += board-tricorder.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RM680)+= board-rm680.o \
sdram-nokia.o
diff --git a/arch/arm/mach-omap2/board-tricorder.c
b/arch/arm/mach-omap2/board-tricorder.c
new file mode 100644
index 000..bafe6a7
--- /dev/null
+++ b/arch/arm/mach-omap2/board-tricorder.c
@@ -0,0 +1,379 @@
+/*
+ * board-tricorder.c - Corscience Tricorder board
+ *
+ * Copyright (C) 2012
+ * Corscience GmbH Co. KG,www.corscience.de
+ * Thomas Weberwe...@corscience.de
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * 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.
+ */
+
+#includelinux/kernel.h
+#includelinux/init.h
+#includelinux/platform_device.h
+#includelinux/delay.h
+#includelinux/err.h
+#includelinux/clk.h
+#includelinux/io.h
+#includelinux/leds.h
+#includelinux/gpio.h
+#includelinux/input.h
+#includelinux/gpio_keys.h
+
+#includelinux/mtd/mtd.h
+#includelinux/mtd/partitions.h
+#includelinux/mtd/nand.h
+#includelinux/mmc/host.h
+
+#includelinux/regulator/machine.h
+#includelinux/i2c/twl.h
+
+#includemach/hardware.h
+#includemach/id.h
+#includeasm/mach-types.h
+#includeasm/mach/arch.h
+#includeasm/mach/map.h
+#includeasm/mach/flash.h
+
+#includeplat/board.h
+#includeplat/gpmc.h
+#includeplat/nand.h
+#includeplat/usb.h
+
+#includelinux/input/matrix_keypad.h
+#includelinux/interrupt.h
+
+#includelinux/i2c/at24.h
+
+#include sdram-micron-mt46h32m32lf-6.h
+
+#include common.h
+#include mux.h
+#include hsmmc.h
+#include common-board-devices.h
+
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition tricorder_nand_partitions[] = {
+ /* All the partitionsizes are listed in terms of NAND block size */
+ {
+ .name = U-Boot SPL,
+ .offset = 0,
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot Env,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 1 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = Kernel,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = File System,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap2_hsmmc_info mmc[] = {
+ {
+ .mmc= 1,
+ .caps =
Re: [PATCH] OMAP3: Add Corscience Tricorder board
Hi, * Thomas Weber thomas.weber.li...@googlemail.com [120216 10:05]: Hello Tony, do you have any comments on this? Well we're trying to remove all the board-*.c files by using device tree, so I suggest starting to look into that a bit. So no new board-*.c files are not being added, unless they're device tree based. If this is similar to your existing board, you may be able to add the support to your existing board file with minimal changes? While things are still being worked on, I can carry board files in the omap tree testing-board branch. 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/RFT 1/1] OMAP2+: cpufreq: scale voltage along with frequency
Use the regulator framework to get the voltage regulator associated
with the MPU voltage domain and use it to scale voltage along with
frequency.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.c |2 ++
drivers/cpufreq/omap-cpufreq.c | 29 -
2 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 8a36342..140c032 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -89,6 +89,8 @@ int voltdm_scale(struct voltagedomain *voltdm,
ret = voltdm-scale(voltdm, target_volt);
if (!ret)
voltdm-nominal_volt = target_volt;
+ printk(KJH: %s: %d\n, __func__, target_volt);
+ dump_stack();
return ret;
}
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 5d04c57..e4f4841 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -25,6 +25,7 @@
#include linux/opp.h
#include linux/cpu.h
#include linux/module.h
+#include linux/regulator/consumer.h
#include asm/system.h
#include asm/smp_plat.h
@@ -52,6 +53,7 @@ static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
static char *mpu_clk_name;
static struct device *mpu_dev;
+static struct regulator *mpu_reg;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
@@ -78,6 +80,8 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int i;
int ret = 0;
struct cpufreq_freqs freqs;
+ struct opp *opp;
+ unsigned long freq, volt;
if (!freq_table) {
dev_err(mpu_dev, %s: cpu%d: no freq table!\n, __func__,
@@ -115,9 +119,26 @@ static int omap_target(struct cpufreq_policy *policy,
pr_info(cpufreq-omap: transition: %u -- %u\n, freqs.old, freqs.new);
#endif
+ freq = freqs.new * 1000;
+ opp = opp_find_freq_ceil(mpu_dev, freq);
+ if (IS_ERR(opp)) {
+ printk(KERN_ERR %s: unable to find MPU OPP for %d\n,
+ __func__, freqs.new);
+ return -EINVAL;
+ }
+ volt = opp_get_voltage(opp);
+
+ /* scaling up? scale voltage before frequency */
+ if (mpu_reg (freqs.new freqs.old))
+ regulator_set_voltage(mpu_reg, volt, volt);
+
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
- freqs.new = omap_getspeed(policy-cpu);
+ /* scaling down? scale voltage after frequency */
+ if (mpu_reg (freqs.new freqs.old))
+ regulator_set_voltage(mpu_reg, volt, volt);
+
+ freqs.new = omap_getspeed(policy-cpu);
#ifdef CONFIG_SMP
/*
* Note that loops_per_jiffy is not updated on SMP systems in
@@ -260,6 +281,12 @@ static int __init omap_cpufreq_init(void)
return -EINVAL;
}
+ mpu_reg = regulator_get(mpu_dev, vcc);
+ if (IS_ERR(mpu_reg)) {
+ pr_warning(%s: unable to get MPU regulator\n, __func__);
+ mpu_reg = NULL;
+ }
+
return cpufreq_register_driver(omap_driver);
}
--
1.7.9
--
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/RFT 0/1] MPU DVFS using SMPS regulator driver
This patch modifies the OMAP CPUfreq driver to use the regulator framework to scale voltage when scaling frequency. It uses the new SMPS regulator driver from Tero. This patch applies on top of the recently posted SMPS regulator series from Tero: Subject: [PATCHv9 0/5] arm: omap: smps regulator support Date:Thu, 16 Feb 2012 12:27:48 +0200 I'd especially appreciate testing from those of you who are setup to measure voltage at the voltage rails and can confirm that voltage is actually being scaled. Kevin Hilman (1): OMAP2+: cpufreq: scale voltage along with frequency arch/arm/mach-omap2/voltage.c |2 ++ drivers/cpufreq/omap-cpufreq.c | 29 - 2 files changed, 30 insertions(+), 1 deletions(-) -- 1.7.9 -- 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/RFT 1/1] OMAP2+: cpufreq: scale voltage along with frequency
Hi Kevin, On Thu, Feb 16, 2012 at 11:20 AM, Kevin Hilman khil...@ti.com wrote: diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c index 8a36342..140c032 100644 --- a/arch/arm/mach-omap2/voltage.c +++ b/arch/arm/mach-omap2/voltage.c @@ -89,6 +89,8 @@ int voltdm_scale(struct voltagedomain *voltdm, ret = voltdm-scale(voltdm, target_volt); if (!ret) voltdm-nominal_volt = target_volt; + printk(KJH: %s: %d\n, __func__, target_volt); + dump_stack(); The debugging letfovers need to be removed. return ret; } Jean -- 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/RFT 1/1] OMAP2+: cpufreq: scale voltage along with frequency
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Kevin,
On Thu, Feb 16, 2012 at 11:20 AM, Kevin Hilman khil...@ti.com wrote:
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 8a36342..140c032 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -89,6 +89,8 @@ int voltdm_scale(struct voltagedomain *voltdm,
ret = voltdm-scale(voltdm, target_volt);
if (!ret)
voltdm-nominal_volt = target_volt;
+ printk(KJH: %s: %d\n, __func__, target_volt);
+ dump_stack();
The debugging letfovers need to be removed.
heh, that's why it's RFT. :)
Here's a version without the stack dumping.
From 62541aac986ee8ba3b67f40de4610068b2d7fbd7 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Fri, 15 Jul 2011 15:05:04 -0700
Subject: [PATCH/RFT 1/1] OMAP2+: cpufreq: scale voltage along with frequency
Use the regulator framework to get the voltage regulator associated
with the MPU voltage domain and use it to scale voltage along with
frequency.
Signed-off-by: Kevin Hilman khil...@ti.com
---
drivers/cpufreq/omap-cpufreq.c | 29 -
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 5d04c57..e4f4841 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -25,6 +25,7 @@
#include linux/opp.h
#include linux/cpu.h
#include linux/module.h
+#include linux/regulator/consumer.h
#include asm/system.h
#include asm/smp_plat.h
@@ -52,6 +53,7 @@ static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
static char *mpu_clk_name;
static struct device *mpu_dev;
+static struct regulator *mpu_reg;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
@@ -78,6 +80,8 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int i;
int ret = 0;
struct cpufreq_freqs freqs;
+ struct opp *opp;
+ unsigned long freq, volt;
if (!freq_table) {
dev_err(mpu_dev, %s: cpu%d: no freq table!\n, __func__,
@@ -115,9 +119,26 @@ static int omap_target(struct cpufreq_policy *policy,
pr_info(cpufreq-omap: transition: %u -- %u\n, freqs.old, freqs.new);
#endif
+ freq = freqs.new * 1000;
+ opp = opp_find_freq_ceil(mpu_dev, freq);
+ if (IS_ERR(opp)) {
+ printk(KERN_ERR %s: unable to find MPU OPP for %d\n,
+ __func__, freqs.new);
+ return -EINVAL;
+ }
+ volt = opp_get_voltage(opp);
+
+ /* scaling up? scale voltage before frequency */
+ if (mpu_reg (freqs.new freqs.old))
+ regulator_set_voltage(mpu_reg, volt, volt);
+
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
- freqs.new = omap_getspeed(policy-cpu);
+ /* scaling down? scale voltage after frequency */
+ if (mpu_reg (freqs.new freqs.old))
+ regulator_set_voltage(mpu_reg, volt, volt);
+
+ freqs.new = omap_getspeed(policy-cpu);
#ifdef CONFIG_SMP
/*
* Note that loops_per_jiffy is not updated on SMP systems in
@@ -260,6 +281,12 @@ static int __init omap_cpufreq_init(void)
return -EINVAL;
}
+ mpu_reg = regulator_get(mpu_dev, vcc);
+ if (IS_ERR(mpu_reg)) {
+ pr_warning(%s: unable to get MPU regulator\n, __func__);
+ mpu_reg = NULL;
+ }
+
return cpufreq_register_driver(omap_driver);
}
--
1.7.9
--
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
[GIT PULL] gpio/omap: cleanup and runtime PM conversion for v3.4
Hi Grant, I've given this a final review and testing and I believe it's ready for 3.4, so here you go. Also note that Benoit's recently posted GPIO cleanups and DT conversion depend on this series. Thanks, Kevin The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab: Linux 3.3-rc2 (2012-01-31 13:31:54 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/gpio/runtime-pm-cleanup for you to fetch changes up to f86bcc302a8c570dd0f5a50097a6af96a0e717c2: gpio/omap: handle set_dataout reg capable IP on restore (2012-02-06 16:58:45 +0530) Charulatha V (8): gpio/omap: remove dependency on gpio_bank_count gpio/omap: use flag to identify wakeup domain gpio/omap: make gpio_context part of gpio_bank structure gpio/omap: make non-wakeup GPIO part of pdata gpio/omap: avoid cpu checks during module ena/disable gpio/omap: use pinctrl offset instead of macro gpio/omap: remove bank-method METHOD_* macros gpio/omap: fix bankwidth for OMAP7xx MPUIO Nishanth Menon (4): gpio/omap: save and restore debounce registers gpio/omap: enable irq at the end of all configuration in restore gpio/omap: restore OE only after setting the output level gpio/omap: handle set_dataout reg capable IP on restore Tarun Kanti DebBarma (13): gpio/omap: handle save/restore context in GPIO driver gpio/omap: further cleanup using wkup_en register gpio/omap: use level/edge detect reg offsets gpio/omap: remove hardcoded offsets in context save/restore gpio/omap: cleanup set_gpio_triggering function gpio/omap: cleanup omap_gpio_mod_init function gpio/omap: remove unnecessary bit-masking for read access gpio/omap: use pm-runtime framework gpio/omap: optimize suspend and resume functions gpio/omap: cleanup prepare_for_idle and resume_after_idle gpio/omap: fix debounce clock handling gpio/omap: fix incorrect access of debounce module gpio/omap: remove omap_gpio_save_context overhead arch/arm/mach-omap1/gpio15xx.c |7 +- arch/arm/mach-omap1/gpio16xx.c | 47 ++- arch/arm/mach-omap1/gpio7xx.c | 14 +- arch/arm/mach-omap2/gpio.c | 36 +- arch/arm/mach-omap2/pm34xx.c | 14 - arch/arm/plat-omap/include/plat/gpio.h | 29 +- drivers/gpio/gpio-omap.c | 1106 +--- 7 files changed, 555 insertions(+), 698 deletions(-) -- 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
[GIT PULL] ARM: OMAP: PM fixes for 3.3-rc
Hi Tony, Here's a couple more OMAP PM fixes for v3.3-rc Kevin The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d: Linux 3.3-rc3 (2012-02-08 19:21:53 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.3/fixes/pm for you to fetch changes up to 03e4fd6eb25e6b46536ecdb0d1b7d33d46b15480: ARM: OMAP4: cpuidle: Fix the C-state reporting to cpuidle governor. (2012-02-14 10:59:26 -0800) NeilBrown (1): ARM: OMAP: add RCU locking to omap2_set_init_voltage. Santosh Shilimkar (1): ARM: OMAP4: cpuidle: Fix the C-state reporting to cpuidle governor. arch/arm/mach-omap2/cpuidle44xx.c |5 ++--- arch/arm/mach-omap2/pm.c |3 +++ 2 files changed, 5 insertions(+), 3 deletions(-) -- 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
[GIT PULL] ARM: OMAP: Miscellaneous DT cleanup for 3.4
Hi Tony, Here is a small cleanup series to prepare for further DT series for 3.4. Thanks, Benoit The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d: Linus Torvalds (1): Linux 3.3-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dt_base Benoit Cousson (5): ARM: OMAP2+: board-generic: Remove un-needed .atag_offset for DT_MACHINE ARM: OMAP2+: omap_device: Replace dev_warn by dev_dbg in omap_device_build_from_dt ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT ARM: OMAP1: kconfig: Enable IRQ_DOMAIN by default for OMAP1 platforms arm/dts: OMAP34: Remove the '0x' prefix for serial nodes arch/arm/boot/dts/omap3.dtsi|8 arch/arm/boot/dts/omap4.dtsi|8 arch/arm/mach-omap2/board-generic.c | 12 arch/arm/mach-omap2/pm.c|8 arch/arm/plat-omap/Kconfig |1 + arch/arm/plat-omap/omap_device.c|2 +- 6 files changed, 22 insertions(+), 17 deletions(-) -- 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/RFT 1/1] OMAP2+: cpufreq: scale voltage along with frequency
Hi Kevin,
On Fri, Feb 17, 2012 at 00:50:43, Hilman, Kevin wrote:
+ /* scaling up? scale voltage before frequency */
+ if (mpu_reg (freqs.new freqs.old))
+ regulator_set_voltage(mpu_reg, volt, volt);
Probably voltage ranges has to be specified, otherwise
if I understand correctly, if exact voltage 'volt'
is a value that cannot be set by voltage regulator,
it may not work properly.
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
- freqs.new = omap_getspeed(policy-cpu);
+ /* scaling down? scale voltage after frequency */
+ if (mpu_reg (freqs.new freqs.old))
+ regulator_set_voltage(mpu_reg, volt, volt);
+
+ freqs.new = omap_getspeed(policy-cpu);
It would be better to handle error cases too,
we have a patch for doing DVFS for AM335X as follows
Regards
Afzal
8--
---
drivers/cpufreq/omap-cpufreq.c | 97 +---
1 files changed, 91 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 5d04c57..a897a9e 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -25,6 +25,7 @@
#include linux/opp.h
#include linux/cpu.h
#include linux/module.h
+#include linux/regulator/consumer.h
#include asm/system.h
#include asm/smp_plat.h
@@ -37,6 +38,8 @@
#include mach/hardware.h
+#define DEFAULT_RESOLUTION 12500
+
#ifdef CONFIG_SMP
struct lpj_info {
unsigned long ref;
@@ -52,6 +55,7 @@ static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
static char *mpu_clk_name;
static struct device *mpu_dev;
+static struct regulator *mpu_reg;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
@@ -78,6 +82,8 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int i;
int ret = 0;
struct cpufreq_freqs freqs;
+ struct opp *opp;
+ int volt_old = 0, volt_new = 0;
if (!freq_table) {
dev_err(mpu_dev, %s: cpu%d: no freq table!\n, __func__,
@@ -105,16 +111,45 @@ static int omap_target(struct cpufreq_policy *policy,
if (freqs.old == freqs.new policy-cur == freqs.new)
return ret;
+ opp = opp_find_freq_exact(mpu_dev, freqs.new * 1000, true);
+ if (IS_ERR(opp)) {
+ dev_err(mpu_dev, %s: cpu%d: no opp match for freq %d\n,
+ __func__, policy-cpu, target_freq);
+ return -EINVAL;
+ }
+
+ volt_new = opp_get_voltage(opp);
+ if (!volt_new) {
+ dev_err(mpu_dev, %s: cpu%d: no opp voltage for freq %d\n,
+ __func__, policy-cpu, target_freq);
+ return -EINVAL;
+ }
+
+ volt_old = regulator_get_voltage(mpu_reg);
+
+#ifdef CONFIG_CPU_FREQ_DEBUG
+ pr_info(cpufreq-omap: frequency transition: %u -- %u\n,
+ freqs.old, freqs.new);
+ pr_info(cpufreq-omap: voltage transition: %d -- %d\n,
+ volt_old, volt_new);
+#endif
+
+ if (freqs.new freqs.old) {
+ ret = regulator_set_voltage(mpu_reg, volt_new,
+ volt_new + DEFAULT_RESOLUTION - 1);
+ if (ret) {
+ dev_err(mpu_dev, %s: unable to set voltage to %d uV
(for %u MHz)\n,
+ __func__, volt_new, freqs.new/1000);
+ return ret;
+ }
+ }
+
/* notifiers */
for_each_cpu(i, policy-cpus) {
freqs.cpu = i;
cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
}
-#ifdef CONFIG_CPU_FREQ_DEBUG
- pr_info(cpufreq-omap: transition: %u -- %u\n, freqs.old, freqs.new);
-#endif
-
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
freqs.new = omap_getspeed(policy-cpu);
@@ -150,6 +185,38 @@ static int omap_target(struct cpufreq_policy *policy,
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
}
+ if (freqs.new freqs.old) {
+ ret = regulator_set_voltage(mpu_reg, volt_new,
+ volt_new + DEFAULT_RESOLUTION - 1);
+ if (ret) {
+ unsigned int temp;
+
+ dev_err(mpu_dev, %s: unable to set voltage to %d uV
(for %u MHz)\n,
+ __func__, volt_new, freqs.new/1000);
+
+ if (clk_set_rate(mpu_clk, freqs.old * 1000)) {
+ dev_err(mpu_dev,
+ %s: failed restoring clock rate to %u
MHz, clock rate is %u MHz,
+ __func__,
+ freqs.old/1000, freqs.new/1000);
+ return ret;
+ }
+
+ temp = freqs.new;
+ freqs.new = freqs.old;
+
Re: SMP local timers and their CPUfreq notifiers setup on OMAP3
(+ linux-arm, Marc) On Thursday 16 February 2012 11:54 PM, Kevin Hilman wrote: Hi Santosh, Using v3.3-rc3 and building an OMAP2+ kernel I noticed that CPUfreq transitions fault because of the TWD cpufreq notifiers being called even on OMAP3. Of course, the TWD doesn't exist on OMAP3, but the TWD init is still setting up notifiers. I tried just adding a !cpu_is_omap44xx() check in local_timer_setup(), but that didn't do it, so there's more timer init that needs to be fixed up. Can you have a look at this? It's easy to reproduce by just manually triggering a frequency change with the userspace governor. Here's what I did on my 3430/n900: Below patch fixes the issue. Regards Santosh From 3a16f7a6694c14e201fdf6ad195c821816b2de84 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Fri, 17 Feb 2012 11:11:28 +0530 Subject: [PATCH] ARM: smp_twd: Don't register CPUFREQ notifiers if local timers are not initialised. Current ARM local timer code registers CPUFREQ notifiers even in case the twd_timer_setup() isn't called. That seems to be wrong and would eventually lead to kernel crash on the CPU frequency transitions on the SOCs where the local timer doesn't exist or broken because of hardware BUG. Fix it by uisng an initialised variable. Though the twd_timer_setup() is percpu, the idea here is to avoid the CPUFREQ registration. Hence percpu initialised variable is not used. The issue was observed with v3.3-rc3 and building an OMAP2+ kernel on OMAP3 SOC which doesn't have TWD. Below is the dump for reference : Unable to handle kernel paging request at virtual address 007e900 pgd = cdc2 [007e9000] *pgd= Internal error: Oops: 5 [#1] SMP Modules linked in: CPU: 0Not tainted (3.3.0-rc3-pm+debug+initramfs #9) PC is at twd_update_frequency+0x34/0x48 LR is at twd_update_frequency+0x10/0x48 pc : [c001382c]lr : [c0013808]psr: 6093 sp : ce311dd8 ip : fp : r10: r9 : 0001 r8 : ce31 r7 : c0440458 r6 : c00137f8 r5 : r4 : c0947a74 r3 : r2 : 007e9000 r1 : r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment usr Control: 10c5387d Table: 8dc20019 DAC: 0015 Process sh (pid: 599, stack limit = 0xce3102f8) Stack: (0xce311dd8 to 0xce312000) 1dc0: 6000c 1de0: 0001 0002 0 1e00: c093d8f0 ce311ebc 0001 0001 ce310 1e20: c001386c c0437c4c c0e95b60 c0e95ba8 0001 c0e95bf8 4 1e40: c005ef74 ce31 c0435cf0 ce311ebc 0 1e60: ce352b40 0007a120 c08d5108 c08ba040 c08ba040 c005f030 0 1e80: c08bc554 c032fe2c 0007a120 c08d4b64 ce352b40 c08d8618 8 1ea0: c08ba040 c033364c ce311ecc c0433b50 0002 ffea c0330 1ec0: 0007a120 0007a120 2201 ce357 1ee0: ce3d6000 cdc2aed8 ce352ba0 c0470164 0002 c032f47c 00034 1f00: c0331cac ce352b40 0007 c032f6d0 ce352bbc 0003d090 c0930 1f20: c093d8bc c03306a4 0007 ce311f80 0007 cdc2aec0 ce358 1f40: ce8d20c0 0007 b6fe5000 ce311f80 0007 ce31 c 1f60: c000de74 ce987400 ce8d20c0 b6fe5000 c 1f80: 001fbac8 0007 001fbac8 4 1fa0: c000df04 c000dd60 0007 001fbac8 0001 b6fe5000 0 1fc0: 0007 001fbac8 0007 0004 b6fe5000 00202 1fe0: beb565f8 00101ffc 8e8c 6010 0001 0 [c001382c] (twd_update_frequency+0x34/0x48) from [c008ac4c] ) [c008ac4c] (smp_call_function_single+0x17c/0x1c8) from [c0013) [c0013890] (twd_cpufreq_transition+0x24/0x30) from [c0437c4c) [c0437c4c] (notifier_call_chain+0x44/0x84) from [c005efe4] () [c005efe4] (__srcu_notifier_call_chain+0x70/0xa4) from [c005f) [c005f030] (srcu_notifier_call_chain+0x18/0x20) from [c032fe2) [c032fe2c] (cpufreq_notify_transition+0xc8/0x1b0) from [c0333) [c033364c] (omap_target+0x1b4/0x28c) from [c032f47c] (__cpuf) [c032f47c] (__cpufreq_driver_target+0x50/0x64) from [c0331d24) [c0331d24] (cpufreq_set+0x78/0x98) from [c032f6d0] (store_sc) [c032f6d0] (store_scaling_setspeed+0x5c/0x74) from [c03306a4) [c03306a4] (store+0x58/0x74) from [c014d868] (sysfs_write_fi) [c014d868] (sysfs_write_file+0x80/0xb4) from [c00f2c2c] (vfs) [c00f2c2c] (vfs_write+0xa8/0x138) from [c00f2e9c] (sys_write) [c00f2e9c] (sys_write+0x40/0x6c) from [c000dd60] (ret_fast_s) Code: e594300c e792210c e1a01000 e5840004 (e7930002) ---[ end trace 5da3b5167c1ecdda ]--- Reported-by: Kevin Hilman khil...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/kernel/smp_twd.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c index 4285daa..753ae37 100644 --- a/arch/arm/kernel/smp_twd.c +++ b/arch/arm/kernel/smp_twd.c @@ -30,6 +30,7 @@ void __iomem *twd_base;
