Re: [PATCH 1/8] ARM: OMAP2+: Move DISPC L3 firewall to happen in omap_display_init()
Hi,
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/display.c |3 +++
drivers/video/omap2/dss/dispc.c |5 -
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3677b1f..5a7f12f 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -191,6 +191,9 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
memset(pdata, 0, sizeof(pdata));
if (cpu_is_omap24xx()) {
+ /* L3 firewall setting: enable access to OCM RAM */
+ __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
+
curr_dss_hwmod = omap2_dss_hwmod_data;
oh_count = ARRAY_SIZE(omap2_dss_hwmod_data);
} else if (cpu_is_omap34xx()) {
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e1626a1..cce0820 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3272,11 +3272,6 @@ static void _omap_dispc_initial_config(void)
if (dss_has_feature(FEAT_FUNCGATED))
REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
- /* L3 firewall setting: enable access to OCM RAM */
- /* XXX this should be somewhere in plat-omap */
- if (cpu_is_omap24xx())
- __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
-
_dispc_setup_color_conv_coef();
dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
I think the whole raw_writel line can be removed. It's been copied from
the old omapfb, and my understanding is that it's about using SRAM for
framebuffer. Using SRAM for fb is no longer supported, and I have a
patch set that removes the remaining SRAM code from omapfb/omapdss.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote: Drivers should no longer use omap_read/write functions but instead use ioremap + read/write functions. As some USB legacy code is still shared between omap1 and omap2420, let's limit the omap_read/write to plat/usb.h. Also, let's make drivers/video/omap/lcdc.c depend on ARCH_OMAP1 as it is not needed for omap2+. I'm ok with the lcdc.c change, but I also have a patch series that makes the same change, plus removes the omap2 code from drivers/video/omap/. Can you check the series, and give ack if the arch/arm side looks fine? It's this one: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/3] OMAPDSS: Miscellaneous DISPC Fixes
On Tue, 2012-02-21 at 19:36 +0530, Archit Taneja wrote: These are some minor Display Controller fixes. Tested on 4430sdp and 3430sdp on the tree: git://gitorious.org/linux-omap-dss2/linux.git dev Lajos Molnar (3): OMAPDSS: DISPC: Fix OMAP4 supported color formats OMAPDSS: DISPC: Fix FIR coefficients OMAPDSS: DSS: Add runtime_pm protection around wait_for_vsync. drivers/video/omap2/dss/dispc.c| 24 +++- drivers/video/omap2/dss/dispc_coefs.c |9 - drivers/video/omap2/dss/dss_features.c |3 ++- 3 files changed, 21 insertions(+), 15 deletions(-) Thanks, I've applied these. Tomi signature.asc Description: This is a digitally signed message part
RE: [GIT PULL] OMAP PM EMU fix for v3.3
Hi Kevin / Paul, I have tested this on beagle board as well as on OMAP3630 based propriatory phone using SDTI serial trace interface. Also you can test it by just observing the CM_EMU (48005100) clkstctrl register 48 = 0001 Across MPU OFF alone [root@beagleboard /]# echo 0 /sys/kernel/debug/pm_debug/neon_pwrdm/suspend [root@beagleboard /]# echo 0 /sys/kernel/debug/pm_debug/mpu_pwrdm/suspend [root@beagleboard /]# echo 1 /sys/kernel/debug/pm_debug/core_pwrdm/suspend [root@beagleboard /]# echo 1 /sys/kernel/debug/pm_debug/per_pwrdm/suspend [root@beagleboard /]# echo mem /sys/power/state [ 59.694671] PM: Syncing filesystems ... done. [ 59.758209] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 59.789947] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 59.820709] Suspending console(s) (use no_console_suspend to debug) [ 60.055816] PM: suspend of devices complete after 212.493 msecs [ 60.059661] PM: late suspend of devices complete after 3.784 msecs [ 60.059753] Disabling non-boot CPUs ... [ 64.299865] Successfully put all powerdomains to target state [ 64.302551] PM: early resume of devices complete after 2.319 msecs [ 64.636444] PM: resume of devices complete after 332.336 msecs [ 64.688446] Restarting tasks ... done. [root@beagleboard /]# And then print again the CM_EMU (48005100) clkstctrl register offset 48 this will have the reset value and PRM_EMU (48307100) offset e4 = 0100 register confirms the domain wakeup reset from OFF. At this moment the SDTI serial trace interface looses connection. With my patch applied the CM_EMU (48005100) clkstctrl register restores it initial setting across MPU OFF. Thanks Gowda -Original Message- From: Kevin Hilman [mailto:khil...@ti.com] Sent: 20 February 2012 17:30 To: Gowda Madhusudhan; Paul Walmsley Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; t...@atomide.com Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3 +Paul Paul maintains the CM core code and should take this patch if he's OK with it. Also, it is most helpful if you describe what platforms it was tested on and exactly how you tested it. Thanks, Kevin madhusudhan.go...@elektrobit.com writes: Hi Kevin, I think you have missed my last mail. Could you please ACK the pull request and pull the same. Best Regards Gowda -Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of linux-arm-kernel-bounces+madhusudhan.gowda=elektrobit.com@lists.infrad linux-arm-kernel-bounces+ea d.org Sent: 28 January 2012 09:58 To: t...@atomide.com; khil...@ti.com Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3 Thanks Tony Hi Kevin Please do the needful and pull the same. Best Regards Gowda -Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of Tony Lindgren Sent: 27 January 2012 21:03 To: Gowda Madhusudhan Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3 Hi, * madhusudhan.go...@elektrobit.com madhusudhan.go...@elektrobit.com [120127 10:25]: Hi Tony, Please pull the PM EMU off mode fix for v3.3 It's best that Kevin queues this as it affects PM. Or it at least needs an ack from Kevin. Regards, Tony Thanks Gowda The following changes since commit 1c6ece3c23e58d0dbc687407d606f3560ded582a: Merge branch 'omap_fixes_a_3.3rc' of git://git.pwsan.com/linux-2.6 (2012-01-26 16:48:37 -0800) are available in the git repository at: git://github.com/elektrobit/linux.git linux-omap-emu-fix Madhusudhan Gowda (1): ARM: OMAP3 PM:Save and restore EMU context across MPU OFF arch/arm/mach-omap2/cm2xxx_3xxx.c | 16 arch/arm/mach-omap2/cm2xxx_3xxx.h |2 ++ arch/arm/mach-omap2/pm34xx.c |8 3 files changed, 22 insertions(+), 4 deletions(-) Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
Latest OMAP randconfig build error
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe': arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first use in this function) arch/arm/mach-omap2/mailbox.c:354: error: (Each undeclared identifier is reported only once arch/arm/mach-omap2/mailbox.c:354: error: for each function it appears in.) There's also these warnings: arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all' defined but not used WARNING: arch/arm/mach-omap2/built-in.o(.text+0x7878): Section mismatch in reference from the function sr_dev_init() to the function .init.text:sr_set_nvalues() The function sr_dev_init() references the function __init sr_set_nvalues(). This is often because sr_dev_init lacks a __init annotation or the annotation of sr_set_nvalues is wrong. Config is at the usual place. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] iommu/omap: fix erroneous omap-iommu-debug API calls
Adapt omap-iommu-debug to the latest omap-iommu API changes, which
were introduced by commit fabdbca iommu/omap: eliminate the public
omap_find_iommu_device() method.
In a nutshell, iommu users are not expected to provide the omap_iommu
handle anymore - instead, iommus are attached using their user's device
handle.
omap-iommu-debug is a hybrid beast though: it invokes both public and
private omap iommu API, so fix it as necessary (otherwise a crash
is imminent).
Note: omap-iommu-debug is a bit disturbing, as it fiddles with internal
omap iommu data and requires exposing API which is otherwise not needed.
It should better be more tightly coupled with omap-iommu, to prevent
further bit rot and avoid exposing redundant API. Naturally that's out
of scope for the -rc cycle, so for now just fix the obvious.
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Tony Lindgren t...@atomide.com
Cc: Hiroshi Doyu hd...@nvidia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Joerg Roedel joerg.roe...@amd.com
---
drivers/iommu/omap-iommu-debug.c | 55 +
1 files changed, 43 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index 288da5c..bad9f9d 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -44,7 +44,8 @@ static ssize_t debug_read_ver(struct file *file, char __user
*userbuf,
static ssize_t debug_read_regs(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct omap_iommu *obj = file-private_data;
+ struct device *dev = file-private_data;
+ struct omap_iommu *obj = dev_to_omap_iommu(dev);
char *p, *buf;
ssize_t bytes;
@@ -67,7 +68,8 @@ static ssize_t debug_read_regs(struct file *file, char __user
*userbuf,
static ssize_t debug_read_tlb(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct omap_iommu *obj = file-private_data;
+ struct device *dev = file-private_data;
+ struct omap_iommu *obj = dev_to_omap_iommu(dev);
char *p, *buf;
ssize_t bytes, rest;
@@ -97,7 +99,8 @@ static ssize_t debug_write_pagetable(struct file *file,
struct iotlb_entry e;
struct cr_regs cr;
int err;
- struct omap_iommu *obj = file-private_data;
+ struct device *dev = file-private_data;
+ struct omap_iommu *obj = dev_to_omap_iommu(dev);
char buf[MAXCOLUMN], *p = buf;
count = min(count, sizeof(buf));
@@ -184,7 +187,8 @@ out:
static ssize_t debug_read_pagetable(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct omap_iommu *obj = file-private_data;
+ struct device *dev = file-private_data;
+ struct omap_iommu *obj = dev_to_omap_iommu(dev);
char *p, *buf;
size_t bytes;
@@ -212,7 +216,8 @@ static ssize_t debug_read_pagetable(struct file *file, char
__user *userbuf,
static ssize_t debug_read_mmap(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct omap_iommu *obj = file-private_data;
+ struct device *dev = file-private_data;
+ struct omap_iommu *obj = dev_to_omap_iommu(dev);
char *p, *buf;
struct iovm_struct *tmp;
int uninitialized_var(i);
@@ -254,7 +259,7 @@ static ssize_t debug_read_mmap(struct file *file, char
__user *userbuf,
static ssize_t debug_read_mem(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct omap_iommu *obj = file-private_data;
+ struct device *dev = file-private_data;
char *p, *buf;
struct iovm_struct *area;
ssize_t bytes;
@@ -268,7 +273,7 @@ static ssize_t debug_read_mem(struct file *file, char
__user *userbuf,
mutex_lock(iommu_debug_lock);
- area = omap_find_iovm_area(obj, (u32)ppos);
+ area = omap_find_iovm_area(dev, (u32)ppos);
if (IS_ERR(area)) {
bytes = -EINVAL;
goto err_out;
@@ -287,7 +292,7 @@ err_out:
static ssize_t debug_write_mem(struct file *file, const char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct omap_iommu *obj = file-private_data;
+ struct device *dev = file-private_data;
struct iovm_struct *area;
char *p, *buf;
@@ -305,7 +310,7 @@ static ssize_t debug_write_mem(struct file *file, const
char __user *userbuf,
goto err_out;
}
- area = omap_find_iovm_area(obj, (u32)ppos);
+ area = omap_find_iovm_area(dev, (u32)ppos);
if (IS_ERR(area)) {
count = -EINVAL;
goto err_out;
@@ -350,7 +355,7 @@ DEBUG_FOPS(mem);
{
[PATCH 2/2] iommu/omap: fix NULL pointer dereference
Fix this:
root@omap4430-panda:~# cat /debug/iommu/ducati/mem
[ 62.725708] Unable to handle kernel NULL pointer dereference at virtual addre
ss 001c
[ 62.725708] pgd = e624
[ 62.737091] [001c] *pgd=a7168831, *pte=, *ppte=
[ 62.743682] Internal error: Oops: 17 [#1] SMP
[ 62.743682] Modules linked in: omap_iommu_debug omap_iovmm virtio_rpmsg_bus o
map_remoteproc remoteproc virtio_ring virtio mailbox_mach mailbox
[ 62.743682] CPU: 0Not tainted (3.3.0-rc1-00265-g382f84e-dirty #682)
[ 62.743682] PC is at debug_read_mem+0x5c/0xac [omap_iommu_debug]
[ 62.743682] LR is at 0x1004
[ 62.777832] pc : [bf033178]lr : [1004]psr: 6013
[ 62.777832] sp : e72c7f40 ip : c0763c00 fp : 0001
[ 62.777832] r10: r9 : r8 : e72c7f80
[ 62.777832] r7 : e6ffdc08 r6 : bed1ac78 r5 : 1000 r4 : e7276000
[ 62.777832] r3 : e60f3460 r2 : r1 : e60f38c0 r0 :
[ 62.777832] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 62.816375] Control: 10c53c7d Table: a624004a DAC: 0015
[ 62.816375] Process cat (pid: 1176, stack limit = 0xe72c62f8)
[ 62.828369] Stack: (0xe72c7f40 to 0xe72c8000)
...
[ 62.884185] [bf033178] (debug_read_mem+0x5c/0xac [omap_iommu_debug]) from [
c010e354] (vfs_read+0xac/0x130)
[ 62.884185] [c010e354] (vfs_read+0xac/0x130) from [c010e4a8] (sys_read+0x
40/0x70)
[ 62.884185] [c010e4a8] (sys_read+0x40/0x70) from [c0014a00] (ret_fast_sys
call+0x0/0x3c)
Fix also its 'echo bla /debug/iommu/ducati/mem' Oops sibling, too.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Tony Lindgren t...@atomide.com
Cc: Hiroshi Doyu hd...@nvidia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Joerg Roedel joerg.roe...@amd.com
---
drivers/iommu/omap-iommu-debug.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index bad9f9d..a2ab29e 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -274,7 +274,7 @@ static ssize_t debug_read_mem(struct file *file, char
__user *userbuf,
mutex_lock(iommu_debug_lock);
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if (IS_ERR_OR_NULL(area)) {
bytes = -EINVAL;
goto err_out;
}
@@ -311,7 +311,7 @@ static ssize_t debug_write_mem(struct file *file, const
char __user *userbuf,
}
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if (IS_ERR_OR_NULL(area)) {
count = -EINVAL;
goto err_out;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iommu/omap: fix NULL pointer dereference
On Wed, Feb 22, 2012 at 10:52:52AM +0200, Ohad Ben-Cohen wrote:
@@ -274,7 +274,7 @@ static ssize_t debug_read_mem(struct file *file, char
__user *userbuf,
mutex_lock(iommu_debug_lock);
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if (IS_ERR_OR_NULL(area)) {
bytes = -EINVAL;
There's something else which needs fixing here - the return code. If
omap_find_iovm_area() returns an error code that needs propagating.
Otherwise it might as well just return NULL for all errors.
--
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/2] iommu/omap: fix NULL pointer dereference
On Wed, Feb 22, 2012 at 10:56 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: There's something else which needs fixing here - the return code. If omap_find_iovm_area() returns an error code that needs propagating. Otherwise it might as well just return NULL for all errors. Seems like it does just return NULL for all errors, so a cleaner fix can probably just be s/IS_ERR(area)/!area/. I'll submit it, but Joerg, if you feel this is becoming a cleanup, feel free to take the first version. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] iommu/omap: fix NULL pointer dereference
Fix this:
root@omap4430-panda:~# cat /debug/iommu/ducati/mem
[ 62.725708] Unable to handle kernel NULL pointer dereference at virtual addre
ss 001c
[ 62.725708] pgd = e624
[ 62.737091] [001c] *pgd=a7168831, *pte=, *ppte=
[ 62.743682] Internal error: Oops: 17 [#1] SMP
[ 62.743682] Modules linked in: omap_iommu_debug omap_iovmm virtio_rpmsg_bus o
map_remoteproc remoteproc virtio_ring virtio mailbox_mach mailbox
[ 62.743682] CPU: 0Not tainted (3.3.0-rc1-00265-g382f84e-dirty #682)
[ 62.743682] PC is at debug_read_mem+0x5c/0xac [omap_iommu_debug]
[ 62.743682] LR is at 0x1004
[ 62.777832] pc : [bf033178]lr : [1004]psr: 6013
[ 62.777832] sp : e72c7f40 ip : c0763c00 fp : 0001
[ 62.777832] r10: r9 : r8 : e72c7f80
[ 62.777832] r7 : e6ffdc08 r6 : bed1ac78 r5 : 1000 r4 : e7276000
[ 62.777832] r3 : e60f3460 r2 : r1 : e60f38c0 r0 :
[ 62.777832] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 62.816375] Control: 10c53c7d Table: a624004a DAC: 0015
[ 62.816375] Process cat (pid: 1176, stack limit = 0xe72c62f8)
[ 62.828369] Stack: (0xe72c7f40 to 0xe72c8000)
...
[ 62.884185] [bf033178] (debug_read_mem+0x5c/0xac [omap_iommu_debug]) from [
c010e354] (vfs_read+0xac/0x130)
[ 62.884185] [c010e354] (vfs_read+0xac/0x130) from [c010e4a8] (sys_read+0x
40/0x70)
[ 62.884185] [c010e4a8] (sys_read+0x40/0x70) from [c0014a00] (ret_fast_sys
call+0x0/0x3c)
Fix also its 'echo bla /debug/iommu/ducati/mem' Oops sibling, too.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Tony Lindgren t...@atomide.com
Cc: Hiroshi Doyu hd...@nvidia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Joerg Roedel joerg.roe...@amd.com
---
v2: omap_find_iovm_area only returns NULL for errors. thanks, rmk.
drivers/iommu/omap-iommu-debug.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index bad9f9d..103dbd9 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -274,7 +274,7 @@ static ssize_t debug_read_mem(struct file *file, char
__user *userbuf,
mutex_lock(iommu_debug_lock);
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if (!area) {
bytes = -EINVAL;
goto err_out;
}
@@ -311,7 +311,7 @@ static ssize_t debug_write_mem(struct file *file, const
char __user *userbuf,
}
area = omap_find_iovm_area(dev, (u32)ppos);
- if (IS_ERR(area)) {
+ if (!area) {
count = -EINVAL;
goto err_out;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iommu/omap: fix NULL pointer dereference
On Wed, Feb 22, 2012 at 11:10:38AM +0200, Ohad Ben-Cohen wrote: On Wed, Feb 22, 2012 at 10:56 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: There's something else which needs fixing here - the return code. If omap_find_iovm_area() returns an error code that needs propagating. Otherwise it might as well just return NULL for all errors. Seems like it does just return NULL for all errors, so a cleaner fix can probably just be s/IS_ERR(area)/!area/. I'll submit it, but Joerg, if you feel this is becoming a cleanup, feel free to take the first version. That sounds more like a bug fix than a cleanup 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: [PATCH 3/3] OMAPDSS: DSS: Add runtime_pm protection around wait_for_vsync.
On Wednesday 22 February 2012 12:19 PM, Tomi Valkeinen wrote: On Wed, 2012-02-22 at 11:15 +0530, Archit Taneja wrote: On Tuesday 21 February 2012 09:38 PM, Tomi Valkeinen wrote: On Tue, 2012-02-21 at 19:36 +0530, Archit Taneja wrote: From: Lajos Molnarla...@ti.com If DSS is suspended during a wait_for_vsync operation, it may loose its clock. Request runtime_pm around wait_for_vsync. Signed-off-by: Lajos Molnarla...@ti.com Signed-off-by: Archit Tanejaarc...@ti.com --- drivers/video/omap2/dss/dispc.c | 16 +++- 1 files changed, 11 insertions(+), 5 deletions(-) This only handles omap_dispc_wait_for_irq_interruptible_timeout(), there's also omap_dispc_wait_for_irq_timeout(). However, I think it'd be better to do the runtime_get/put in the caller, instead of in these dispc's wait funcs. While it doesn't really matter with dss_mgr_wait_for_vsync(), for dss_mgr/ovl_wait_for_go() it makes much more sense to get/put there just once, instead of every time the omap_dispc_wait_* is called. Right, that makes sense. Btw, in the current code, how do we ensure that clocks are enabled when someone calls omap_dss_mgr_apply(). We don't. Apply does not touch any of the registers if the corresponding manager is not enabled, so there's no need to enable clocks. Okay, so if a manager is disabled, we won't write to the registers, but still update the private data of the manager and connected overlays, and these will be later written to the registers once the manager gets enabled. Makes sense. In the older apply, we used to always enable clocks, even if we wrote to registers or not. So I got mixed up with that. Thanks, Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest OMAP randconfig build error
+ Tony, Suman
On Wed, Feb 22, 2012 at 10:51 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first
use in this function)
arch/arm/mach-omap2/mailbox.c:354: error: (Each undeclared identifier is
reported only once
arch/arm/mach-omap2/mailbox.c:354: error: for each function it appears in.)
The below should trivially solve this, but I wonder if there was any
other merit in explicitly using CONFIG_SOC_OMAP2420 there (any
different between 2420 and 2430 in that respect ?).
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 609ea2d..e61d275 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -258,7 +258,7 @@ struct omap_mbox mbox_dsp_info = {
struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
#endif
-#if defined(CONFIG_SOC_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP2)
/* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv10 3/4] omap3: add common twl configurations for vdd1 and vdd2
On Tue, 2012-02-21 at 16:00 -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
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
manuals:
- SWCS019L : TWL4030 ES3.1 Data Manual rev L
- SWCS030E : TWL5030 ES1.2 Data Manual rev E
Signed-off-by: Tero Kristo t-kri...@ti.com
Do you have a similar patch for OMAP4 support?
It looks like OMAP4 support requires some changes to the twl-regulator /
twl-core in addition to the twl-common.c. I have these available (just
created them), should I post these out? Attached here for reference in
case you need to test something quickly.
-Tero
From 4bee5804e8f20af94ecfe170dd4c5df984bdca6c Mon Sep 17 00:00:00 2001
From: Tero Kristo t-kri...@ti.com
Date: Wed, 22 Feb 2012 12:36:58 +0200
Subject: [PATCH 1/2] regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators
vdd1 and vdd2 are now common regulators for twl4030 and twl6030. Also
added vdd3 as a new regulator for twl6030. twl6030 vdd1...vdd3 smps
regulator voltages can only be controlled through the smartreflex
voltage channel, thus the support for the voltage_get and set is
minimal and requires external controller.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/mfd/twl-core.c| 15 ++
drivers/regulator/twl-regulator.c | 39 +
include/linux/i2c/twl.h |5 ++-
3 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index fae5f76..c788e36 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -949,6 +949,21 @@ add_children(struct twl4030_platform_data *pdata, unsigned long features)
/* twl6030 regulators */
if (twl_has_regulator() twl_class_is_6030()
!(features TWL6025_SUBCLASS)) {
+ child = add_regulator(TWL6030_REG_VDD1, pdata-vdd1,
+ features);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ child = add_regulator(TWL6030_REG_VDD2, pdata-vdd2,
+ features);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
+ child = add_regulator(TWL6030_REG_VDD3, pdata-vdd3,
+ features);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+
child = add_regulator(TWL6030_REG_VMMC, pdata-vmmc,
features);
if (IS_ERR(child))
diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index 0afc9e1a..55a0e4d 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -561,6 +561,32 @@ static struct regulator_ops twl4030smps_ops = {
.get_voltage = twl4030smps_get_voltage,
};
+static int twl6030coresmps_set_voltage(struct regulator_dev *rdev, int min_uV,
+ int max_uV, unsigned *selector)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ if (info-set_voltage)
+ return info-set_voltage(info-data, min_uV);
+
+ return 0;
+}
+
+static int twl6030coresmps_get_voltage(struct regulator_dev *rdev)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ if (info-get_voltage)
+ return info-get_voltage(info-data);
+
+ return 0;
+}
+
+static struct regulator_ops twl6030coresmps_ops = {
+ .set_voltage = twl6030coresmps_set_voltage,
+ .get_voltage = twl6030coresmps_get_voltage,
+};
+
static int twl6030ldo_list_voltage(struct regulator_dev *rdev, unsigned index)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
@@ -918,6 +944,16 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
+#define TWL6030_ADJUSTABLE_SMPS(label) { \
+ .desc = { \
+ .name = #label, \
+ .id = TWL6030_REG_##label, \
+ .ops = twl6030coresmps_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .owner = THIS_MODULE, \
+ }, \
+ }
+
#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
.base = offset, \
.min_mV = min_mVolts, \
@@ -1019,6 +1055,9 @@ static struct twlreg_info twl_regs[] = {
/* 6030 REG with base as PMC Slave Misc : 0x0030 */
/* Turnon-delay and remap configuration values for 6030 are not
verified since the specification is not public */
+ TWL6030_ADJUSTABLE_SMPS(VDD1),
+ TWL6030_ADJUSTABLE_SMPS(VDD2),
+ TWL6030_ADJUSTABLE_SMPS(VDD3),
TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000, 3300),
TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000, 3300),
TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000, 3300),
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 08a82d3..f66c031 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -712,6 +712,9 @@ struct twl4030_platform_data {
struct regulator_init_data *vaux1;
struct regulator_init_data *vaux2;
struct regulator_init_data *vaux3;
+ struct regulator_init_data *vdd1;
+ struct regulator_init_data *vdd2;
+ struct regulator_init_data *vdd3;
/* TWL4030 LDO regulators */
struct regulator_init_data *vpll1;
struct regulator_init_data *vpll2;
@@ -720,8 +723,6 @@
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 01/27/2012 06:29 PM, Cousson, Benoit :
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
Hi,
I followed that discussion and I like very much the biding that Benoit
is proposing. It will help me a lot with my current work on Atmel DMA
controller.
If I understand correctly, some rework is needed before it can be
integrated in a stable git tree (I mean before we can base our work on
top of it). So, in the meantime, what should I do to help and make
things go forward? to be quite frank, I would be interested to have a
working DMA enabled device soon ;-)
Do you think that 3.4 is out of reach?
Best regards,
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
Documentation/devicetree/bindings/dma/dma.txt | 44 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 130
+
include/linux/of_dma.h| 49 +
5 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..7f2a301
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,44 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required properties:
+- dma-controller: Mark the device as a DMA controller
+- #dma-cells: Number of cell for each DMA line, must be one.
+
+
+Example:
+
+ sdma: dma-controller@4800 {
+ compatible = ti,sdma-omap4
+ reg = 0x4800 0x1000;
+ interrupts = 12;
+dma-controller;
+ #dma-cells = 1;
+ };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request numbers using a phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
+
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma-request = sdma 2 sdma 3;
+dma-request-names = tx, rx;
+...
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+ def_bool y
+ help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..d08443b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO)+= of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..d4927e2
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,130 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_dma.h
+
+/**
+ * of_get_dma_request() - Get a DMA request number and dma-controller node
+ * @np: device node to get DMA request from
+ * @propname:property name containing DMA specifier(s)
+ * @index: index of the DMA request
+ * @ctrl_np: a device_node pointer to fill in
+ *
+ * Returns DMA number along to the dma controller node, or one of the errno
+ * value on the error condition. If @ctrl_np is not NULL the function also
+ * fills in the DMA controller device_node pointer.
+ */
+int of_get_dma_request(struct device_node *np, int index,
+struct device_node **ctrl_np)
+{
+ int ret = -EINVAL;
+ struct of_phandle_args dma_spec;
+
+ ret = of_parse_phandle_with_args(np, dma-request,
ks8851 speed regression in kernel 3.0.17-115c
Hi! Current kernel: linux-3.0.17-r115c Download speed: 745kB/sec Previous kernel: 2.6.32-r78 Download speed: 1MB/sec I noticed the regression in speed for ks8851 driver (Micrel KSZ8851-SNL). I used this part with kernel 2.6.32 and the speed was 1MB/s. Then the driver code was changed and for current Linux version linux-3.0.17-r115c the speed is 745kB/s. 25% speed reduce is indeed noticeable. I use Angstrom Linux built in OE environment. Target board is Beagleboard C4. -- 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
tps65930: MIC does not work
Hi! I use Angstrom Linux with devkit8000 where TPS65930 is installed. Current kernel version is linux-3.0.17-r115c. I can't enable MIC working while it worked in 2.6.28-omap and 2.6.32-r78. I suspect the MIC Bias control does not function because I can't see any voltage level at a microphone jack. Trying to use alsamixer does not let me achieve the goal. I already set registers to necessary values (borrowed from working 2.6.28-omap) but no sound is still captured from a mic by arecord utility. Please suggest how to fix this issue. Thanks in advance. Max -- 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
Questions about DSS device tree adaptation
Hi,
I'd like to get some feedback for the DSS DT work.
I have currently this in omap4.dtsi, under ocp. It's still a hack, for
example there's sdi for testing even though omap4 doesn't have SDI
output.
dss {
compatible = ti,omap4-dss;
ti,hwmods = dss_core;
dispc {
compatible = ti,omap4-dispc;
ti,hwmods = dss_dispc;
};
dpi: dpi {
compatible = ti,omap4-dpi;
};
sdi: sdi {
compatible = ti,omap3-sdi;
};
dsi1: dsi@1 {
compatible = ti,omap4-dsi;
ti,hwmods = dss_dsi1;
id = 0;
vdds_dsi-supply = vcxio;
};
dsi2: dsi@2 {
compatible = ti,omap4-dsi;
ti,hwmods = dss_dsi2;
id = 1;
vdds_dsi-supply = vcxio;
};
hdmi {
compatible = ti,omap4-hdmi;
ti,hwmods = dss_hdmi;
hpd_gpio = 0;
ls_oe = 0;
};
rfbi: rfbi {
compatible = ti,omap4-rfbi;
ti,hwmods = dss_rfbi;
};
venc {
compatible = ti,omap4-venc;
ti,hwmods = dss_venc;
};
};
And in omap4-panda.dtsi I have:
dpi {
dvi {
compatible = ti,tfp410;
data-lines = 24;
channel = 2;
enable-gpio = 0;
ddc = dviddc;
};
};
A few notes/questions about the above:
dispc is not an output interface (so it won't have any children), it
doesn't have anything to customize in the dt data, and it's present on
all OMAPs. Should it still be present in the DT data, or should the
device be created dynamically in platform code?
dpi and sdi are not hwmods as the rest of the nodes. They are, from HW
point of view, more or less parts of DSS or perhaps DISPC.
dsi nodes have the id property, which is used by the driver to choose
between DSI1 and DSI2 HW modules. Is there a better way to do this than
a custom property?
Who/where/when should the devices for dss submodules be created? The
device for dss-node is created automatically by the of-platform code(?),
but the rest of the submodules need to be handled by me somehow.
I'm currently using of_platform_populate() in the probe of ti,omap4-dss
driver to create the subdevices, but this approach doesn't feel right.
Shouldn't the devices be created already at the boot time by platform
code, not by the driver code?
Is the simple-bus, that ocp node also uses, something that I could use
here? If I define the dss node to be compatible with simple-bus also,
does it mean that the of-platform code creates the submodules for me?
Are there any side-effects?
How about the actual panel devices. Above there's the ti,tfp410
device. The panel devices are not plain platform devices, so I need to
handle those myself. Can I somehow handle that in the platform code,
creating omap_dss_devices at boot time, or do I need to create those
devices in, for example in this case, dpi-driver's probe?
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On 02/15/2012 10:04 AM, Benoit Cousson wrote:
Adapt the GPIO driver to retrieve information from a DT file.
Allocate the irq_base dynamically and rename bank-virtual_irq_start
to bank-irq_base.
Change irq_base type to int instead of u16 to match irq_alloc_descs
output.
Add documentation for GPIO properties specific to OMAP.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
One comment below, but otherwise:
Acked-by: Rob Herring rob.herr...@calxeda.com
---
.../devicetree/bindings/gpio/gpio-omap.txt | 30 +
drivers/gpio/gpio-omap.c | 121
++--
2 files changed, 142 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
new file mode 100644
index 000..c1b3100
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -0,0 +1,30 @@
+OMAP GPIO controller bindings
+
+Required properties:
+- compatible:
+ - ti,omap2-gpio for OMAP2 controllers
+ - ti,omap3-gpio for OMAP3 controllers
+ - ti,omap4-gpio for OMAP4 controllers
+- #gpio-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+- #interrupt-cells : Should be one
There's no level/edge settings for gpios?
+- interrupt-controller: Mark the device node as an interrupt controller
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the GPIO:
+ gpioX, X being the 1-based instance number from the HW spec
+
+
+Example:
+
+gpio4: gpio4 {
+compatible = ti,omap4-gpio;
+ti,hwmods = gpio4;
+#gpio-cells = 2;
+gpio-controller;
+#interrupt-cells = 1;
+interrupt-controller;
+};
+
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c3a9dc8..bc2bd69 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -22,6 +22,9 @@
#include linux/device.h
#include linux/pm_runtime.h
#include linux/pm.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/irqdomain.h
#include mach/hardware.h
#include asm/irq.h
@@ -52,7 +55,8 @@ struct gpio_bank {
struct list_head node;
void __iomem *base;
u16 irq;
- u16 virtual_irq_start;
+ int irq_base;
+ struct irq_domain *domain;
u32 suspend_wakeup;
u32 saved_wakeup;
u32 non_wakeup_gpios;
@@ -669,7 +673,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
if (!isr)
break;
- gpio_irq = bank-virtual_irq_start;
+ gpio_irq = bank-irq_base;
for (; isr != 0; isr = 1, gpio_irq++) {
gpio_index = GPIO_INDEX(bank, irq_to_gpio(gpio_irq));
@@ -915,7 +919,7 @@ static int gpio_2irq(struct gpio_chip *chip, unsigned
offset)
struct gpio_bank *bank;
bank = container_of(chip, struct gpio_bank, chip);
- return bank-virtual_irq_start + offset;
+ return bank-irq_base + offset;
}
/*-*/
@@ -1028,8 +1032,7 @@ static void __devinit omap_gpio_chip_init(struct
gpio_bank *bank)
gpiochip_add(bank-chip);
- for (j = bank-virtual_irq_start;
- j bank-virtual_irq_start + bank-width; j++) {
+ for (j = bank-irq_base; j bank-irq_base + bank-width; j++) {
irq_set_lockdep_class(j, gpio_lock_class);
irq_set_chip_data(j, bank);
if (bank-is_mpuio) {
@@ -1044,15 +1047,22 @@ static void __devinit omap_gpio_chip_init(struct
gpio_bank *bank)
irq_set_handler_data(bank-irq, bank);
}
+static const struct of_device_id omap_gpio_match[];
+
static int __devinit omap_gpio_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
+ struct device_node *node = dev-of_node;
+ const struct of_device_id *match;
struct omap_gpio_platform_data *pdata;
struct resource *res;
struct gpio_bank *bank;
int ret = 0;
- if (!dev-platform_data)
+ match = of_match_device(of_match_ptr(omap_gpio_match), dev);
+
+ pdata = match ? match-data : dev-platform_data;
+ if (!pdata)
return -EINVAL;
bank = devm_kzalloc(pdev-dev, sizeof(struct gpio_bank), GFP_KERNEL);
@@ -1068,9 +1078,6 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
}
bank-irq = res-start;
-
- pdata = pdev-dev.platform_data;
- bank-virtual_irq_start = pdata-virtual_irq_start;
bank-dev = dev;
bank-dbck_flag = pdata-dbck_flag;
bank-stride = pdata-bank_stride;
@@ -1080,6 +1087,18 @@ static int
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On 2/22/2012 3:23 PM, Rob Herring wrote: On 02/15/2012 10:04 AM, Benoit Cousson wrote: Adapt the GPIO driver to retrieve information from a DT file. Allocate the irq_base dynamically and rename bank-virtual_irq_start to bank-irq_base. Change irq_base type to int instead of u16 to match irq_alloc_descs output. Add documentation for GPIO properties specific to OMAP. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Tarun Kanti DebBarmatarun.ka...@ti.com One comment below, but otherwise: Acked-by: Rob Herringrob.herr...@calxeda.com --- .../devicetree/bindings/gpio/gpio-omap.txt | 30 + drivers/gpio/gpio-omap.c | 121 ++-- 2 files changed, 142 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt new file mode 100644 index 000..c1b3100 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt @@ -0,0 +1,30 @@ +OMAP GPIO controller bindings + +Required properties: +- compatible: + - ti,omap2-gpio for OMAP2 controllers + - ti,omap3-gpio for OMAP3 controllers + - ti,omap4-gpio for OMAP4 controllers +- #gpio-cells : Should be two. + - first cell is the pin number + - second cell is used to specify optional parameters (unused) +- gpio-controller : Marks the device node as a GPIO controller. +- #interrupt-cells : Should be one There's no level/edge settings for gpios? That's a good question, because I was wondering as well :-) I did no see how it was done in other GPIO implementation. 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: [PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
On Tue, Feb 14, 2012 at 11:08:36AM +, Russell King - ARM Linux wrote:
Two more points:
On Mon, Feb 13, 2012 at 11:43:42AM -0500, Matt Porter wrote:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616f04d1f5da0e07bec4e0092f227 added the requirement
Always include the commit summary as well here, so:
Commit c7e963f616 (net/smsc911x: Add regulator support) added the ...
Ok. Addressed in v2.
@@ -55,6 +94,11 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
+ if (platform_device_register(gpmc_smsc911x_regulator) 0) {
+ pr_err(Unable to register smsc911x regulators\n);
+ return;
+ }
It's always a good idea to indicate why something failed:
err = platform_device_register(gpmc_smsc911x_regulator);
if (err 0) {
pr_err(Unable to register smsc911x regulators: %d\n, err);
return;
}
so that people can see not only what failed, but also why it failed.
Looks much better, also addressed in v2.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
---
Changes for v2:
- temporary fix to avoid platform device id conflicts
- add commit summary from the smsc911x regulator support commit
- incorporate platform device registration error cause reporting
arch/arm/mach-omap2/gpmc-smsc911x.c | 54 ++-
1 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 9970331..a7388ed 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,6 +19,8 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/smsc911x.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
#include plat/board.h
#include plat/gpmc.h
@@ -42,6 +44,50 @@ static struct smsc911x_platform_config gpmc_smsc911x_config
= {
.flags = SMSC911X_USE_16BIT,
};
+static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
+/* Generic regulator definition to satisfy smsc911x */
+static struct regulator_init_data gpmc_smsc911x_reg_init_data = {
+ .constraints = {
+ .min_uV = 330,
+ .max_uV = 330,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(gpmc_smsc911x_supply),
+ .consumer_supplies = gpmc_smsc911x_supply,
+};
+
+static struct fixed_voltage_config gpmc_smsc911x_fixed_reg_data = {
+ .supply_name= gpmc_smsc911x,
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .startup_delay = 0,
+ .enable_high= 0,
+ .enabled_at_boot= 1,
+ .init_data = gpmc_smsc911x_reg_init_data,
+};
+
+/*
+ * Platform device id of 42 is a temporary fix to avoid conflicts
+ * with other reg-fixed-voltage devices. The real fix should
+ * involve the driver core providing a way of dynamically
+ * assigning a unique id on registration for platform devices
+ * in the same name space.
+ */
+static struct platform_device gpmc_smsc911x_regulator = {
+ .name = reg-fixed-voltage,
+ .id = 42,
+ .dev = {
+ .platform_data = gpmc_smsc911x_fixed_reg_data,
+ },
+};
+
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -51,10 +97,16 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
{
struct platform_device *pdev;
unsigned long cs_mem_base;
- int ret;
+ int ret, err;
gpmc_cfg = board_data;
+ err = platform_device_register(gpmc_smsc911x_regulator);
+ if (err 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n, err);
+ return;
+ }
+
if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
pr_err(Failed to request GPMC mem region\n);
return;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] omap: fix omap2plus defaults for am35xx parts
On Thu, Feb 09, 2012 at 03:16:24PM -0500, Matt Porter wrote: This series enables all current am35xx boards and the on-chip Ethernet driver in omap2plus_defconfig. It will help users of these boards to have a working defconfig out of the box. Matt Porter (2): omap: enable davinci_emac in omap2plus_defconfig for am35xx omap: build am3517crane board support by default arch/arm/configs/omap2plus_defconfig |1 + arch/arm/mach-omap2/Kconfig |1 + 2 files changed, 2 insertions(+), 0 deletions(-) Can these be queued for 3.4? It would be great to have omap2plus_defconfig build craneboard support by default to help catch any future regressions. -Matt -- 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] adding rpmsg and remoteproc to 3.4
Hi Arnd, Please pull: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git rpmsg-for-3.4 To get the very basic rpmsg+remoteproc core functionality for 3.4. This is basically the same stuff I sent for 3.3, with an additional fix and cleanup which were reported by Grant (and of course the two patches that fixed the 3.3 merge conflicts). This entire patch set has been sitting in linux-next for quite some time. I'm not sure if it'd conflict with your tree when you pull it, but I can of course ask Stephen to remove my tree if things look ok to you. Please tell me if there are any problems, Thanks a lot! Ohad. The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: Linux 3.3-rc1 (2012-01-19 15:04:48 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git rpmsg-for-3.4 for you to fetch changes up to e12bc14b88d44e5c1456dccb59ff58103f6c6edc: remoteproc: s/big switch/lookup table/ (2012-02-22 18:28:49 +0200) Adding the rpmsg and remoteproc frameworks, together with several bug fixes and clean ups that were collected along the way. Only very basic functionality is merged at this point (boot a remote processor, possibly after configuring its iommu, and then be able to talk with it). And there's a small rpmsg driver sample that shows how easy it is now to talk with a service running on a remote processor. At this point only OMAP4 is supported (but note that we're not populating OMAP's platform device yet, since it depends on CMA), but support for other platforms is coming soon too. Axel Lin (1): rpmsg: rename virtqueue_add_buf_gfp to virtqueue_add_buf Mark Grosen (2): remoteproc: do not require an iommu remoteproc: avoid registering a virtio device if not supported Ohad Ben-Cohen (16): remoteproc: add framework for controlling remote processors remoteproc: add debugfs entries remoteproc: create rpmsg virtio device remoteproc/omap: add a remoteproc driver for OMAP4 rpmsg: add virtio-based remote processor messaging bus samples/rpmsg: add an rpmsg driver sample remoteproc: remove unused resource type remoteproc/omap: utilize module_platform_driver remoteproc: look for truncated firmware images remoteproc: add Kconfig menu rpmsg: add Kconfig menu remoteproc: depend on EXPERIMENTAL rpmsg: depend on EXPERIMENTAL remoteproc: don't use virtio's weak barriers remoteproc: bail out if firmware has different endianess remoteproc: s/big switch/lookup table/ Documentation/ABI/testing/sysfs-bus-rpmsg| 75 ++ Documentation/remoteproc.txt | 324 ++ Documentation/rpmsg.txt | 293 ++ MAINTAINERS |7 + arch/arm/plat-omap/include/plat/remoteproc.h | 57 + drivers/Kconfig |4 + drivers/Makefile |2 + drivers/remoteproc/Kconfig | 29 + drivers/remoteproc/Makefile |9 + drivers/remoteproc/omap_remoteproc.c | 238 + drivers/remoteproc/omap_remoteproc.h | 69 ++ drivers/remoteproc/remoteproc_core.c | 1450 ++ drivers/remoteproc/remoteproc_debugfs.c | 179 drivers/remoteproc/remoteproc_internal.h | 44 + drivers/remoteproc/remoteproc_rpmsg.c| 299 ++ drivers/rpmsg/Kconfig| 10 + drivers/rpmsg/Makefile |1 + drivers/rpmsg/virtio_rpmsg_bus.c | 1026 ++ include/linux/mod_devicetable.h |9 + include/linux/remoteproc.h | 271 + include/linux/rpmsg.h| 326 ++ include/linux/virtio_ids.h |1 + samples/Kconfig |8 + samples/Makefile |2 +- samples/rpmsg/Makefile |1 + samples/rpmsg/rpmsg_client_sample.c | 100 ++ 26 files changed, 4833 insertions(+), 1 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-rpmsg create mode 100644 Documentation/remoteproc.txt create mode 100644 Documentation/rpmsg.txt create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h create mode 100644 drivers/remoteproc/Kconfig create mode 100644 drivers/remoteproc/Makefile create mode 100644 drivers/remoteproc/omap_remoteproc.c create mode 100644 drivers/remoteproc/omap_remoteproc.h create mode 100644 drivers/remoteproc/remoteproc_core.c create mode 100644 drivers/remoteproc/remoteproc_debugfs.c create mode 100644 drivers/remoteproc/remoteproc_internal.h create mode 100644 drivers/remoteproc/remoteproc_rpmsg.c create mode 100644
Re: [PATCH] gpio/omap: fix wakeups on level-triggered GPIOs
On Wed, Feb 22, 2012 at 12:31 AM, Kevin Hilman khil...@ti.com wrote:
While both level- and edge-triggered GPIOs are capable of generating
interrupts, only edge-triggered GPIOs are capable of generating a
module-level wakeup to the PRCM (c.f. 34xx NDA TRM section 25.5.3.2.)
In order to ensure that devices using level-triggered GPIOs as
interrupts can also cause wakeups (e.g. from idle), this patch enables
edge-triggering for wakeup-enabled, level-triggered GPIOs when a GPIO
bank is runtime-suspended (which also happens during idle.)
This fixes a problem found in GPMC-connected network cards with GPIO
interrupts (e.g. smsc911x on Zoom3, Overo, ...) where network booting
with NFSroot was very slow since the GPIO IRQs used by the NIC were
not generating PRCM wakeups, and thus not waking the system from idle.
NOTE: until v3.3, this boot-time problem was somewhat masked because
the UART init prevented WFI during boot until the full serial driver
was available. Preventing WFI allowed regular GPIO interrupts to fire
and this problem was not seen. After the UART runtime PM cleanups, we
no longer avoid WFI during boot, so GPIO IRQs that were not causing
wakeups resulted in very slow IRQ response times.
Tested on platforms using level-triggered GPIOs for network IRQs using
the SMSC911x NIC: 3530/Overo and 3630/Zoom3.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@ti.com
I have tested on OMAP3430 by making modification to touchscreen GPIO.
(I had similar change in my next planned cleanup/fix series.)
If needed you can add my Tested-by:
--
Tarun
---
This applies on top of the GPIO cleanup and runtime PM conversion series
which has been submitted for v3.4 and also available here:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
for_3.4/gpio/runtime-pm-cleanup
drivers/gpio/gpio-omap.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f49bd6f..752ae9b 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1196,8 +1196,30 @@ static int omap_gpio_runtime_suspend(struct device
*dev)
struct gpio_bank *bank = platform_get_drvdata(pdev);
u32 l1 = 0, l2 = 0;
unsigned long flags;
+ u32 wake_low, wake_hi;
spin_lock_irqsave(bank-lock, flags);
+
+ /*
+ * Only edges can generate a wakeup event to the PRCM.
+ *
+ * Therefore, ensure any wake-up capable GPIOs have
+ * edge-detection enabled before going idle to ensure a wakeup
+ * to the PRCM is generated on a GPIO transition. (c.f. 34xx
+ * NDA TRM 25.5.3.1)
+ *
+ * The normal values will be restored upon -runtime_resume()
+ * by writing back the values saved in bank-context.
+ */
+ wake_low = bank-context.leveldetect0 bank-context.wake_en;
+ if (wake_low)
+ __raw_writel(wake_low | bank-context.fallingdetect,
+ bank-base + bank-regs-fallingdetect);
+ wake_hi = bank-context.leveldetect1 bank-context.wake_en;
+ if (wake_hi)
+ __raw_writel(wake_hi | bank-context.risingdetect,
+ bank-base + bank-regs-risingdetect);
+
if (bank-power_mode != OFF_MODE) {
bank-power_mode = 0;
goto update_gpio_context_count;
@@ -1246,6 +1268,18 @@ static int omap_gpio_runtime_resume(struct device *dev)
spin_lock_irqsave(bank-lock, flags);
_gpio_dbck_enable(bank);
+
+ /*
+ * In -runtime_suspend(), level-triggered, wakeup-enabled
+ * GPIOs were set to edge trigger also in order to be able to
+ * generate a PRCM wakeup. Here we restore the
+ * pre-runtime_suspend() values for edge triggering.
+ */
+ __raw_writel(bank-context.fallingdetect,
+ bank-base + bank-regs-fallingdetect);
+ __raw_writel(bank-context.risingdetect,
+ bank-base + bank-regs-risingdetect);
+
if (!bank-enabled_non_wakeup_gpios || !bank-workaround_enabled) {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
--
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
--
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/5] gpio/omap: Add DT support to GPIO driver
On 02/22/2012 08:31 AM, Cousson, Benoit wrote: On 2/22/2012 3:23 PM, Rob Herring wrote: On 02/15/2012 10:04 AM, Benoit Cousson wrote: Adapt the GPIO driver to retrieve information from a DT file. Allocate the irq_base dynamically and rename bank-virtual_irq_start to bank-irq_base. Change irq_base type to int instead of u16 to match irq_alloc_descs output. Add documentation for GPIO properties specific to OMAP. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Tarun Kanti DebBarmatarun.ka...@ti.com One comment below, but otherwise: Acked-by: Rob Herringrob.herr...@calxeda.com --- .../devicetree/bindings/gpio/gpio-omap.txt | 30 + drivers/gpio/gpio-omap.c | 121 ++-- 2 files changed, 142 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt new file mode 100644 index 000..c1b3100 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt @@ -0,0 +1,30 @@ +OMAP GPIO controller bindings + +Required properties: +- compatible: + - ti,omap2-gpio for OMAP2 controllers + - ti,omap3-gpio for OMAP3 controllers + - ti,omap4-gpio for OMAP4 controllers +- #gpio-cells : Should be two. + - first cell is the pin number + - second cell is used to specify optional parameters (unused) +- gpio-controller : Marks the device node as a GPIO controller. +- #interrupt-cells : Should be one There's no level/edge settings for gpios? That's a good question, because I was wondering as well :-) I did no see how it was done in other GPIO implementation. There's not really a good example that I've found. Many gpio nodes don't even have interrupt-controller set. So if you have an irq_set_type function for gpio's, then you should have 2 cells. Rob -- 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: Latest OMAP randconfig build error
* Ohad Ben-Cohen o...@wizery.com [120222 01:30]:
+ Tony, Suman
On Wed, Feb 22, 2012 at 10:51 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first
use in this function)
arch/arm/mach-omap2/mailbox.c:354: error: (Each undeclared identifier is
reported only once
arch/arm/mach-omap2/mailbox.c:354: error: for each function it appears in.)
The below should trivially solve this, but I wonder if there was any
other merit in explicitly using CONFIG_SOC_OMAP2420 there (any
different between 2420 and 2430 in that respect ?).
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 609ea2d..e61d275 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -258,7 +258,7 @@ struct omap_mbox mbox_dsp_info = {
struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
#endif
-#if defined(CONFIG_SOC_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP2)
/* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
2430 is like omap3 for the mailbox. So the code we have seems
wrong trying to initialize it like 2420 mailbox. So we either
need a new entry for omap2430_mboxes[], or should just bail
out from the probe for 2430 for the fix.
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] gpio/omap: fix wakeups on level-triggered GPIOs
* DebBarma, Tarun Kanti tarun.ka...@ti.com [120222 08:46]: On Wed, Feb 22, 2012 at 12:31 AM, Kevin Hilman khil...@ti.com wrote: While both level- and edge-triggered GPIOs are capable of generating interrupts, only edge-triggered GPIOs are capable of generating a module-level wakeup to the PRCM (c.f. 34xx NDA TRM section 25.5.3.2.) In order to ensure that devices using level-triggered GPIOs as interrupts can also cause wakeups (e.g. from idle), this patch enables edge-triggering for wakeup-enabled, level-triggered GPIOs when a GPIO bank is runtime-suspended (which also happens during idle.) This fixes a problem found in GPMC-connected network cards with GPIO interrupts (e.g. smsc911x on Zoom3, Overo, ...) where network booting with NFSroot was very slow since the GPIO IRQs used by the NIC were not generating PRCM wakeups, and thus not waking the system from idle. NOTE: until v3.3, this boot-time problem was somewhat masked because the UART init prevented WFI during boot until the full serial driver was available. Preventing WFI allowed regular GPIO interrupts to fire and this problem was not seen. After the UART runtime PM cleanups, we no longer avoid WFI during boot, so GPIO IRQs that were not causing wakeups resulted in very slow IRQ response times. Tested on platforms using level-triggered GPIOs for network IRQs using the SMSC911x NIC: 3530/Overo and 3630/Zoom3. Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com I have tested on OMAP3430 by making modification to touchscreen GPIO. (I had similar change in my next planned cleanup/fix series.) If needed you can add my Tested-by: Work for me too: Tested-by: Tony Lindgren t...@atomide.com -- 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 03/16] OMAPDSS: Remove video SRAM support
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: OMAP SRAM can be used as video memory on OMAP1 and 2. However, there usually is very little SRAM available, thus limiting its use, and no board supported by the kernel currently uses it. This patch removes the use of SRAM as video ram for the omapdss driver to simplify memory handling. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com For the arch/arm/*omap*/* parts: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/16] OMAPFB: Remove video SRAM support (old omapfb)
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: OMAP SRAM can be used as video memory on OMAP1 and 2. However, there usually is very little SRAM available, thus limiting its use, and no board supported by the kernel currently uses it. This patch removes the use of SRAM as video ram for the old omapfb driver to simplify memory handling. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/16] OMAP2+: remove unneeded #include omapfb.h
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/io.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 3f174d5..7fee69c 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -21,7 +21,6 @@ #include linux/init.h #include linux/io.h #include linux/clk.h -#include linux/omapfb.h #include asm/tlb.h Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/16] OMAP: N770: remove HWA742 platform data
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: In an effort to clean up the old omapfb driver, this patch removes HWA742 (the display chip used in N770) platform data. This can be done as N770 is the only user of HWA742, and the platform data contains only one field, te_connected, which we can just presume to be true in the HWA742 driver. This allows us to remove omapfb_set_ctrl_platform_data(), and the mechanism to pass the platform data, in a later patch. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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 07/16] OAMPFB: remove unused omapfb_set_ctrl_platform_data()
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: omapfb_set_ctrl_platform_data() is no longer used, so it can be removed. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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 08/16] OMAPFB: remove early mem alloc from old omapfb
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: arch/arm/plat-omap/fb.c contains code to alloc omapfb buffers at early boot time according to information given from the bootloader or board file. This code isn't currently used by any board, and is anyway something that the newer vram.c could handle. So remove the alloc code and in later patches make old omapfb driver use vram.c. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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 12/16] OMAPFB: remove omapfb_set_platform_data()
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: omapfb_set_platform_data() is no longer used, so remove it. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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 13/16] OMAP1: pass LCD config with omapfb_set_lcd_config()
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: LCD config for old omapfb driver is passed with OMAP_TAG_LCD from board files or from the bootloader. In an effort to remove OMAP_TAG_LCD, this patch adds omapfb_set_lcd_config() function that the board files can call to set the LCD config. This has the drawback that configuration can no longer come from the bootloader. Of the boards supported by the kernel, this should only affect N770 which depends on the data from the bootloader. This patch adds an LCD config for N770 to its board files, but that is most probably broken. Fixing this would need information about the HW setup in N770 boards. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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 14/16] OMAP: Remove OMAP_TAG_LCD and OMAP_TAG_FBMEM
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: These tags are no longer used and can be removed. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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 15/16] OMAP1: Remove unused LCD devices from board files
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: Some OMAP1 board files define LCD platform_devices, but there are no corresponding LCD drivers for those in the kernel. Thus remove these LCD devices. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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 16/16] OMAPFB: remove remaining OMAP arch checks
* Tomi Valkeinen tomi.valkei...@ti.com [120124 01:30]: Now that the old omapfb driver is only omap1 display driver, there's no need to check if the arch is omap1. This patch removes the few remaining checks for the arch. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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/5] gpio/omap: Add DT support to GPIO driver
Rob Herring wrote at Wednesday, February 22, 2012 10:23 AM: On 02/22/2012 08:31 AM, Cousson, Benoit wrote: On 2/22/2012 3:23 PM, Rob Herring wrote: On 02/15/2012 10:04 AM, Benoit Cousson wrote: Adapt the GPIO driver to retrieve information from a DT file. Allocate the irq_base dynamically and rename bank-virtual_irq_start to bank-irq_base. Change irq_base type to int instead of u16 to match irq_alloc_descs output. Add documentation for GPIO properties specific to OMAP. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Tarun Kanti DebBarmatarun.ka...@ti.com One comment below, but otherwise: Acked-by: Rob Herringrob.herr...@calxeda.com --- .../devicetree/bindings/gpio/gpio-omap.txt | 30 + drivers/gpio/gpio-omap.c | 121 ++-- 2 files changed, 142 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt new file mode 100644 index 000..c1b3100 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt @@ -0,0 +1,30 @@ +OMAP GPIO controller bindings + +Required properties: +- compatible: + - ti,omap2-gpio for OMAP2 controllers + - ti,omap3-gpio for OMAP3 controllers + - ti,omap4-gpio for OMAP4 controllers +- #gpio-cells : Should be two. + - first cell is the pin number + - second cell is used to specify optional parameters (unused) +- gpio-controller : Marks the device node as a GPIO controller. +- #interrupt-cells : Should be one There's no level/edge settings for gpios? That's a good question, because I was wondering as well :-) I did no see how it was done in other GPIO implementation. There's not really a good example that I've found. Many gpio nodes don't even have interrupt-controller set. So if you have an irq_set_type function for gpio's, then you should have 2 cells. Tegra's GPIO IRQ binding (gpio_nvidia.txt in linux-next at least) says: - #interrupt-cells : Should be 2. The first cell is the GPIO number. The second cell is used to specify flags: bits[3:0] trigger type and level flags: 1 = low-to-high edge triggered. 2 = high-to-low edge triggered. 4 = active high level-sensitive. 8 = active low level-sensitive. Valid combinations are 1, 2, 3, 4, 8. Presumably, that's what you meant. -- nvpublic -- 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
Mohammed, Afzal af...@ti.com writes: Hi Kevin, On Wed, Feb 22, 2012 at 05:36:12, Hilman, Kevin wrote: In this case, volt comes from the OPP table, and was requested using a rounding call into the OPP table, so the resolution problem is handled there. If 'volt' cannot be set by the regulator, then the OPP tables are also broken. Also, in your patch, you only add some offset. If you want to be approximate, shouldn't you have plus and minus? IMO, we should let the OPP table handle that, and not the CPUfreq driver. I have a different opinion. Consider following case, Voltage to set for OPPX is 1262.5mV and regulator has steps of 10mV, and suppose regulator steps are .., 1260mV, 1270mV etc. Regulator framework will not be able to set voltage for OPPX (certainly if set_voltage_sel is used) if no range specified. But instead if range of 1262.5 - (1262.5 + 10 - 1) is provided, regulator can certainly set voltage for 1270mV (a nearest value) Resolution in my patch was not meant to be resolution per se, it was meant so that a voltage step can always be found for the regulator (assuming worst resolution is 12.5mV), and for regulator to get a step, resolution had to be used. I agree, if the OPP table doesn't represent actual voltages, then some sort of range needs to be used. Ideal solution may be to use a variable to have a default resolution of worst regulator and update it to that of regulator used (perhaps making use of something like module parameters) If regulator for a particular SoC is changed, exact OPP voltage may not be settable, but a near value should be sufficient, this can't be achieved if range is not specified. That happens exactly for AM335X, voltage for one of OPP is 1.26V, but as regulator cannot set the value, it is being set at 1.2625V and if no range is specified, it will not work. And in my patch plus - minus was not used as regulator framework will try to set voltage for the least voltage which sometimes corresponds to exact OPP required value. sometimes? Using your example above, what if the closest value was 1.259V? Wouldn't you then need +/- range? For cpufreq omap driver to work with various regulators, it would be better to specify ranges. I am fine with that, and am open for proposals. Feel free to send a patch on top of my v2. I agree, my version is not very robust in the face of errors from the regulator framework. Hoever, I'm not crazy about the extra notifications in your proposed patch. I think it's cleaner to always pre and post notify. If there's a failure, the post notify will have the same freq as the pre-notify, but that's not a big problem. Yes, agree that error handling path is bulky. A problem that can happen is that drivers who has registered cpufreq notifier will think that frequency has changed, that may cause problem in addition to delay time getting altered. But whether these are worth handling with a penalty of bulky error handling, probably you know better. Please have a look at my v2. The drivers will get pre and post notifiers, with the caveat that upon DVFS failure, the freq in the post notifier might be the same as the one in the pre notifier, indicating that no change was made. 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 00/16] OMAPDSS: old OMAPFB cleanup
* Tomi Valkeinen tomi.valkei...@ti.com [120214 03:21]: Hi Tony, On Tue, 2012-01-24 at 12:00 +0200, Tomi Valkeinen wrote: Now that all omap2+ boards have been changed to use the newer omapdss driver, this patch series removes omap2+ support from the old omapfb driver (drivers/video/omap), and thus makes it an omap1 dss/fb driver. The use of SRAM for video ram had earlier been disabled by removing the SRAM allocation (fee926bb0d399b1eaaf38f9f694bbf2747c4b8a2), and now this series also removes the support from the omap fb drivers. Also various cleanup patches allow us to remove remove OMAP_TAG_LCD and OMAP_TAG_FBMEM. All in all, the series removes quite a bit of unneeded code and cleans up the links between the board files and the display drivers, and this should help with device tree adaptation. Great, looks good to me. I've acked the arch/arm/*omap*/* patches. There may be some trivial merge conflicts with the includes with my cleanup branch for the io.h changes. Some of the patches affect the newer omapdss and omapfb drivers, but mostly the patches deal with omap1. I have compile tested the series for both omap1 and omap2, but I have only tested this on OMAP3 and OMAP4 boards, as I don't have OMAP1/2 boards. I think N770's display won't work after these patches, but other OMAP1 boards should be ok. To fix N770's display requires knowledge of the hardware setup, which is currently passed from the bootloader. Tony, do you have any feedback on this? I think the arch/arm changes are quite clean as such, but are you ok with (possibly) breaking N770's display? The other OMAP1 boards should, at least in theory, work as well as before. For N770, the bootloader passes the reset GPIO number and number of datalines, and I have no idea what those are. I think they should be: conf-nreset_gpio = 13 conf-data_lines = 24 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 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
* Tomi Valkeinen tomi.valkei...@ti.com [120221 23:42]: On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote: Drivers should no longer use omap_read/write functions but instead use ioremap + read/write functions. As some USB legacy code is still shared between omap1 and omap2420, let's limit the omap_read/write to plat/usb.h. Also, let's make drivers/video/omap/lcdc.c depend on ARCH_OMAP1 as it is not needed for omap2+. I'm ok with the lcdc.c change, but I also have a patch series that makes the same change, plus removes the omap2 code from drivers/video/omap/. OK, I'll drop the lcdc.c change from my series as that should only affect randconfig builds. Can you check the series, and give ack if the arch/arm side looks fine? It's this one: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup Yeah great, I've acked those. Let's do a test merge when I have these in cleanup branch, looks like the conflicts should be trivial. 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 1/8] ARM: OMAP2+: Move DISPC L3 firewall to happen in omap_display_init()
* Tomi Valkeinen tomi.valkei...@ti.com [120221 23:38]:
Hi,
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/display.c |3 +++
drivers/video/omap2/dss/dispc.c |5 -
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3677b1f..5a7f12f 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -191,6 +191,9 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
memset(pdata, 0, sizeof(pdata));
if (cpu_is_omap24xx()) {
+ /* L3 firewall setting: enable access to OCM RAM */
+ __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
+
curr_dss_hwmod = omap2_dss_hwmod_data;
oh_count = ARRAY_SIZE(omap2_dss_hwmod_data);
} else if (cpu_is_omap34xx()) {
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index e1626a1..cce0820 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3272,11 +3272,6 @@ static void _omap_dispc_initial_config(void)
if (dss_has_feature(FEAT_FUNCGATED))
REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
- /* L3 firewall setting: enable access to OCM RAM */
- /* XXX this should be somewhere in plat-omap */
- if (cpu_is_omap24xx())
- __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
-
_dispc_setup_color_conv_coef();
dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
I think the whole raw_writel line can be removed. It's been copied from
the old omapfb, and my understanding is that it's about using SRAM for
framebuffer. Using SRAM for fb is no longer supported, and I have a
patch set that removes the remaining SRAM code from omapfb/omapdss.
OK, I'll remove those from drivers/video/omap2/dss/dispc.c so this
series keeps building.
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: [PATCHv10 3/4] omap3: add common twl configurations for vdd1 and vdd2
Tero Kristo t-kri...@ti.com writes: On Tue, 2012-02-21 at 16:00 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: 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 manuals: - SWCS019L : TWL4030 ES3.1 Data Manual rev L - SWCS030E : TWL5030 ES1.2 Data Manual rev E Signed-off-by: Tero Kristo t-kri...@ti.com Do you have a similar patch for OMAP4 support? It looks like OMAP4 support requires some changes to the twl-regulator / twl-core in addition to the twl-common.c. I have these available (just created them), should I post these out? Yes please. Attached here for reference in case you need to test something quickly. Thanks, it's easier for me to validate actual voltage scaling on OMAP4 since I have a setup to easily measure voltage rails. Thanks for these, I verified they work using my v2 CPUfreq driver on OMAP4430. 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: Latest OMAP randconfig build error
On Wed, Feb 22, 2012 at 11:58 AM, Tony Lindgren t...@atomide.com wrote:
* Ohad Ben-Cohen o...@wizery.com [120222 01:30]:
+ Tony, Suman
On Wed, Feb 22, 2012 at 10:51 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
arch/arm/mach-omap2/mailbox.c: In function 'omap2_mbox_probe':
arch/arm/mach-omap2/mailbox.c:354: error: 'omap2_mboxes' undeclared (first
use in this function)
arch/arm/mach-omap2/mailbox.c:354: error: (Each undeclared identifier is
reported only once
arch/arm/mach-omap2/mailbox.c:354: error: for each function it appears in.)
The below should trivially solve this, but I wonder if there was any
other merit in explicitly using CONFIG_SOC_OMAP2420 there (any
different between 2420 and 2430 in that respect ?).
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 609ea2d..e61d275 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -258,7 +258,7 @@ struct omap_mbox mbox_dsp_info = {
struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
#endif
-#if defined(CONFIG_SOC_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP2)
/* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
2430 is like omap3 for the mailbox. So the code we have seems
wrong trying to initialize it like 2420 mailbox. So we either
need a new entry for omap2430_mboxes[], or should just bail
out from the probe for 2430 for the fix.
Yes, current code tries to configure both mboxes in a 2430, however it
shouldn't be assigning an irq line for the iva mbox, and any request
for iva mbox should fail due to that.
Code is wrong to register both in 2430 though.
Regards,
Omar
--
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: Latest OMAP randconfig build error
On Wed, Feb 22, 2012 at 7:58 PM, Tony Lindgren t...@atomide.com wrote:
2430 is like omap3 for the mailbox.
Gotcha, thanks.
This one below isn't pretty, but it should satisfy all build
permutations and still be correct hw-wise.
If it looks good to you I'll submit it properly.
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 609ea2d..6f0f228 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -281,8 +281,14 @@ static struct omap_mbox mbox_iva_info = {
.ops= omap2_mbox_ops,
.priv = omap2_mbox_iva_priv,
};
+#endif
-struct omap_mbox *omap2_mboxes[] = { mbox_dsp_info, mbox_iva_info, NULL };
+#if defined(CONFIG_ARCH_OMAP2)
+struct omap_mbox *omap2_mboxes[] = { mbox_dsp_info,
+#if defined(CONFIG_SOC_OMAP2420)
+ mbox_iva_info,
+#endif
+ NULL };
#endif
#if defined(CONFIG_ARCH_OMAP4)
--
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: Latest OMAP randconfig build error
On Wed, Feb 22, 2012 at 09:55:56PM +0200, Ohad Ben-Cohen wrote:
On Wed, Feb 22, 2012 at 7:58 PM, Tony Lindgren t...@atomide.com wrote:
2430 is like omap3 for the mailbox.
Gotcha, thanks.
This one below isn't pretty, but it should satisfy all build
permutations and still be correct hw-wise.
If it looks good to you I'll submit it properly.
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 609ea2d..6f0f228 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -281,8 +281,14 @@ static struct omap_mbox mbox_iva_info = {
.ops= omap2_mbox_ops,
.priv = omap2_mbox_iva_priv,
};
+#endif
-struct omap_mbox *omap2_mboxes[] = { mbox_dsp_info, mbox_iva_info, NULL };
+#if defined(CONFIG_ARCH_OMAP2)
+struct omap_mbox *omap2_mboxes[] = { mbox_dsp_info,
+#if defined(CONFIG_SOC_OMAP2420)
+ mbox_iva_info,
+#endif
+ NULL };
Better would be:
+#ifdef CONFIG_ARCH_OMAP2
+struct omap_mbox *omap2_mboxes[] = {
+ mbox_dsp_info,
+#ifdef CONFIG_SOC_OMAP2420
+ mbox_iva_info,
+#endif
+ NULL
+};
#endif
There's no point in typing any more than you have to with #if defined().
The only place where using #if defined() makes sense is if you want to
subsequently do #elif defined xxx because there isn't a #elifdef.
--
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: Latest OMAP randconfig build error
On Wed, Feb 22, 2012 at 10:12 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
+#ifdef CONFIG_ARCH_OMAP2
+struct omap_mbox *omap2_mboxes[] = {
+ mbox_dsp_info,
+#ifdef CONFIG_SOC_OMAP2420
+ mbox_iva_info,
+#endif
+ NULL
+};
#endif
Beautiful. 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] gpio/omap: fix wakeups on level-triggered GPIOs
Hi Tarun, DebBarma, Tarun Kanti tarun.ka...@ti.com writes: On Wed, Feb 22, 2012 at 12:31 AM, Kevin Hilman khil...@ti.com wrote: While both level- and edge-triggered GPIOs are capable of generating interrupts, only edge-triggered GPIOs are capable of generating a module-level wakeup to the PRCM (c.f. 34xx NDA TRM section 25.5.3.2.) In order to ensure that devices using level-triggered GPIOs as interrupts can also cause wakeups (e.g. from idle), this patch enables edge-triggering for wakeup-enabled, level-triggered GPIOs when a GPIO bank is runtime-suspended (which also happens during idle.) This fixes a problem found in GPMC-connected network cards with GPIO interrupts (e.g. smsc911x on Zoom3, Overo, ...) where network booting with NFSroot was very slow since the GPIO IRQs used by the NIC were not generating PRCM wakeups, and thus not waking the system from idle. NOTE: until v3.3, this boot-time problem was somewhat masked because the UART init prevented WFI during boot until the full serial driver was available. Preventing WFI allowed regular GPIO interrupts to fire and this problem was not seen. After the UART runtime PM cleanups, we no longer avoid WFI during boot, so GPIO IRQs that were not causing wakeups resulted in very slow IRQ response times. Tested on platforms using level-triggered GPIOs for network IRQs using the SMSC911x NIC: 3530/Overo and 3630/Zoom3. Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com I have tested on OMAP3430 by making modification to touchscreen GPIO. (I had similar change in my next planned cleanup/fix series.) If needed you can add my Tested-by: Thanks for testing, I'll add a Tested-by from you and Tony before submitting to Grant. 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: help: BeagleBoard xM RevC ethernet port
Peter Ujfalusi peter.ujfal...@ti.com writes: Hi, I hoped that time will solve this, but so far no luck. I just can not get the ethernet port (along with the USB host ports) working on my xM RevC. What is the trick to get it working on 3.3-rc3? There seams to be some configuration issue: [1.437530] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.444671] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96 [1.451354] ehci-omap ehci-omap.0: failed to get ehci port0 regulator [1.458282] ehci-omap ehci-omap.0: failed to get ehci port1 regulator The first thing I try when I see these regulator failures is to add CONFIG_REGULATOR_DUMMY=y to the .config to see if that helps. If so, then the board file needs some help configuring the right regulators. 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 00/16] OMAPDSS: old OMAPFB cleanup
* Tony Lindgren t...@atomide.com [120222 10:18]: * Tomi Valkeinen tomi.valkei...@ti.com [120214 03:21]: Tony, do you have any feedback on this? I think the arch/arm changes are quite clean as such, but are you ok with (possibly) breaking N770's display? The other OMAP1 boards should, at least in theory, work as well as before. For N770, the bootloader passes the reset GPIO number and number of datalines, and I have no idea what those are. I think they should be: conf-nreset_gpio = 13 conf-data_lines = 24 Probably should be: conf-nreset_gpio = 13 conf-data_lines = 16 No luck getting anything on the LCD though with current kernel 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
[PATCH] cbus: Fix lines for Nokia 770
From 54c4785b8d274f8d282b4243945ae0b17edf4686 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Wed, 22 Feb 2012 13:03:07 -0800
Subject: [PATCH] cbus: Fix lines for Nokia 770
This makes retu and tahvo work again on Nokia 770 so it
stays running.
Signed-off-by: Tony Lindgren t...@atomide.com
---
I applied this into cbus branch as it seems to fix retu
watchdog for Nokia 770.
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -87,9 +87,9 @@ static struct platform_device nokia770_kp_device = {
#if defined(CONFIG_CBUS) || defined(CONFIG_CBUS_MODULE)
static struct cbus_host_platform_data nokia770_cbus_data = {
- .clk_gpio = OMAP_MPUIO(11),
+ .clk_gpio = OMAP_MPUIO(9),
.dat_gpio = OMAP_MPUIO(10),
- .sel_gpio = OMAP_MPUIO(9),
+ .sel_gpio = OMAP_MPUIO(11),
};
static struct platform_device nokia770_cbus_device = {
--
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/8] ARM: OMAP2+: Move DISPC L3 firewall to happen in omap_display_init()
* Tony Lindgren t...@atomide.com [120222 10:34]:
* Tomi Valkeinen tomi.valkei...@ti.com [120221 23:38]:
Hi,
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/display.c |3 +++
drivers/video/omap2/dss/dispc.c |5 -
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 3677b1f..5a7f12f 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -191,6 +191,9 @@ int __init omap_display_init(struct
omap_dss_board_info *board_data)
memset(pdata, 0, sizeof(pdata));
if (cpu_is_omap24xx()) {
+ /* L3 firewall setting: enable access to OCM RAM */
+ __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
+
curr_dss_hwmod = omap2_dss_hwmod_data;
oh_count = ARRAY_SIZE(omap2_dss_hwmod_data);
} else if (cpu_is_omap34xx()) {
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index e1626a1..cce0820 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3272,11 +3272,6 @@ static void _omap_dispc_initial_config(void)
if (dss_has_feature(FEAT_FUNCGATED))
REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
- /* L3 firewall setting: enable access to OCM RAM */
- /* XXX this should be somewhere in plat-omap */
- if (cpu_is_omap24xx())
- __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
-
_dispc_setup_color_conv_coef();
dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
I think the whole raw_writel line can be removed. It's been copied from
the old omapfb, and my understanding is that it's about using SRAM for
framebuffer. Using SRAM for fb is no longer supported, and I have a
patch set that removes the remaining SRAM code from omapfb/omapdss.
OK, I'll remove those from drivers/video/omap2/dss/dispc.c so this
series keeps building.
Here's this one updated.
Tony
From: Tony Lindgren t...@atomide.com
Date: Mon, 20 Feb 2012 12:55:07 -0800
Subject: [PATCH] ARM: OMAP2+: Drop DISPC L3 firewall code
This is only needed when using SRAM for framebuffer,
and the support for SRAM framebuffer is about to get
removed.
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3272,11 +3272,6 @@ static void _omap_dispc_initial_config(void)
if (dss_has_feature(FEAT_FUNCGATED))
REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
- /* L3 firewall setting: enable access to OCM RAM */
- /* XXX this should be somewhere in plat-omap */
- if (cpu_is_omap24xx())
- __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
-
_dispc_setup_color_conv_coef();
dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
--
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 09:31 -0800, Kevin Hilman wrote:
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
It does something for the issue, but I still get this during suspend to
off:
[ 11.284973] PM: Syncing filesystems ... done.
[ 11.379241] Freezing user space processes ... (elapsed 0.02 seconds)
done.
[ 11.408233] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) don
e.
[ 11.439239] Suspending console(s) (use no_console_suspend to debug)
[ 11.564178] PM: suspend of devices complete after 115.506 msecs
[ 11.567382] PM: late suspend of devices complete after 3.204 msecs
[ 11.567443] Disabling non-boot CPUs ...
[ 12.004089] Powerdomain (cam_pwrdm) didn't enter target state 0
[ 12.004119] Could not enter target state in pm_suspend
[ 12.009368] PM: early resume of devices complete after 4.944 msecs
[ 12.436645] PM: resume of devices complete after 426.086 msecs
[ 12.480285] Restarting tasks ... done.
/sys/kernel/debu[ 12.488433] [ cut here ]
[ 12.494415] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1604 _idle
+0x164/0x1
7c()
[ 12.502258] omap_hwmod: gpio6: idle state can only be entered from
enabled st
Re: [GIT PULL] gpio/omap: cleanup and runtime PM conversion for v3.4
Hi Grant, Any objections to this series? Can we get this queued and into linux-next? I'll have an additional pull request for Benoit's GPIO DT stuff that depends on this for v3.4 too after that series is finalized. Thanks, Kevin On 02/16/2012 12:43 PM, Kevin Hilman wrote: 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
Re: [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
* Tony Lindgren t...@atomide.com [120222 10:27]:
* Tomi Valkeinen tomi.valkei...@ti.com [120221 23:42]:
On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.
As some USB legacy code is still shared between omap1 and
omap2420, let's limit the omap_read/write to plat/usb.h.
Also, let's make drivers/video/omap/lcdc.c depend on
ARCH_OMAP1 as it is not needed for omap2+.
I'm ok with the lcdc.c change, but I also have a patch series that makes
the same change, plus removes the omap2 code from drivers/video/omap/.
OK, I'll drop the lcdc.c change from my series as that should
only affect randconfig builds.
Here's this one updated. Noticed one more legacy driver
that needs omap_read/write defined to build on 2420.
Regards,
Tony
Date: Tue, 21 Feb 2012 13:27:33 -0800
Subject: [PATCH] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.
As some USB legacy code is still shared between omap1 and
omap2420, let's limit the omap_read/write to plat/usb.h.
Note that the long term fix is to update the drivers to
use ioremap and read/write functions. That can now be
done as a separate patch series that is limited to the
USB drivers.
Also make sure the legacy omap1-keypad.c driver builds
if selected for 2420 based systems.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 09ca9e9..f78ec4e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -242,15 +242,5 @@ struct omap_sdrc_params;
extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
-/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
- */
-extern u8 omap_readb(u32 pa);
-extern u16 omap_readw(u32 pa);
-extern u32 omap_readl(u32 pa);
-extern void omap_writeb(u8 v, u32 pa);
-extern void omap_writew(u16 v, u32 pa);
-extern void omap_writel(u32 v, u32 pa);
-
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 0119807..3203128 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -487,43 +487,3 @@ void __init omap_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
_omap2_init_reprogram_sdrc();
}
}
-
-/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
- */
-
-u8 omap_readb(u32 pa)
-{
- return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readb);
-
-u16 omap_readw(u32 pa)
-{
- return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readw);
-
-u32 omap_readl(u32 pa)
-{
- return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readl);
-
-void omap_writeb(u8 v, u32 pa)
-{
- __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writeb);
-
-void omap_writew(u16 v, u32 pa)
-{
- __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writew);
-
-void omap_writel(u32 v, u32 pa)
-{
- __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writel);
diff --git a/arch/arm/plat-omap/include/plat/keypad.h
b/arch/arm/plat-omap/include/plat/keypad.h
index 793ce9d..4b3 100644
--- a/arch/arm/plat-omap/include/plat/keypad.h
+++ b/arch/arm/plat-omap/include/plat/keypad.h
@@ -12,6 +12,8 @@
#ifndef CONFIG_ARCH_OMAP1
#warning Please update the board to use matrix-keypad driver
+#define omap_readw(reg)0
+#define omap_writew(val, reg) do {} while(0)
#endif
#include linux/input/matrix_keypad.h
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index dc864b5..5f6ced4 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -3,6 +3,7 @@
#ifndef__ASM_ARCH_OMAP_USB_H
#define__ASM_ARCH_OMAP_USB_H
+#include linux/io.h
#include linux/usb/musb.h
#include plat/board.h
@@ -105,6 +106,45 @@ extern int omap4430_phy_set_clk(struct device *dev, int
on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
extern int omap4430_phy_suspend(struct device *dev, int suspend);
+
+/*
+ * NOTE: Please update omap USB drivers to use ioremap + read/write
+ */
+
+#define OMAP2_L4_IO_OFFSET 0xb200
+#define OMAP2_L4_IO_ADDRESS(pa)IOMEM((pa) + OMAP2_L4_IO_OFFSET)
+
+static inline u8 omap_readb(u32 pa)
+{
+ return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline u16 omap_readw(u32 pa)
+{
+ return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline u32 omap_readl(u32 pa)
+{
+ return
Re: Latest OMAP randconfig build error
* Ohad Ben-Cohen o...@wizery.com [120222 11:51]:
On Wed, Feb 22, 2012 at 10:12 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
+#ifdef CONFIG_ARCH_OMAP2
+struct omap_mbox *omap2_mboxes[] = {
+ mbox_dsp_info,
+#ifdef CONFIG_SOC_OMAP2420
+ mbox_iva_info,
+#endif
+ NULL
+};
#endif
Beautiful. Thanks!
Care to post an updated patch for me to apply into fixes?
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 1/7] OMAP: 4430SDP: Correct fixed regulator device ID
* Peter Ujfalusi peter.ujfal...@ti.com [120210 01:34]: The board has two fixed voltage regulator. Correct the device ID for the vbat, which used -1. Create defines for the fixed regulator IDs so when adding new regulators we know the next available ID to use for them. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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 4/7] OMAP4: twl-common: Add twl6030 V1V8, V2V1 SMPS common configuration
* Peter Ujfalusi peter.ujfal...@ti.com [120210 01:34]: V1V8 supply from twl6030 commonly used as VIO for the machine. V2V1 is adviced to supply the twl6040, and also to feed the twl6030's VCXIO_IN, and VDAC_IN inputs. Create the common regulator configurations for these regulators: Make the V2V1 as supply_regulator for VCXIO, VDAC. Add twl6040 (1-004b) as consumer for V1V8, and V2V1. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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 5/7] OMAP: 4430SDP: Use common configuration for V1V8, V2V1 supplies
* Peter Ujfalusi peter.ujfal...@ti.com [120210 01:34]: These supplies going to be needed for the twl6040 driver. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- 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/7] OMAP: omap4panda: Use common configuration for V1V8, V2V1 supplies
* Peter Ujfalusi peter.ujfal...@ti.com [120210 01:34]: These supplies going to be needed for the twl6040 driver. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: panda: Correct cpu version check for 4430
* Peter Ujfalusi peter.ujfal...@ti.com [120217 00:56]: The cpu_is_omap4430() macro always return with 0. Use the correct cpu_is_omap443x() to check for Panda revision. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi, Since the depending patches are going via Liam's tree it would be best if we can queue this via audio as well. Without this patch the audio on Panda 4430 is not working correctly. Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: dma: Correct CPU version check for dma_common_ch_end
* Peter Ujfalusi peter.ujfal...@ti.com [120217 00:54]: CCDN is the last common channel register in all OMAP4 versions. Use cpu_is_omap44xx() instead of the cpu_is_omap4430() - which is anyway not doing what it supposed to do. This is a bit unclear.. Which is not doing what is supposed to do? DMA driver? Or one of the cpu_is_omap? If this should be queued as a fix, then we need some kind of description here what breaks. Regards, Tony Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap2/dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c index a59a45a..b19d849 100644 --- a/arch/arm/mach-omap2/dma.c +++ b/arch/arm/mach-omap2/dma.c @@ -227,7 +227,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused) dma_stride = OMAP2_DMA_STRIDE; dma_common_ch_start = CSDP; - if (cpu_is_omap3630() || cpu_is_omap4430()) + if (cpu_is_omap3630() || cpu_is_omap44xx()) dma_common_ch_end = CCDN; else dma_common_ch_end = CCFN; -- 1.7.8.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: [PATCH v2] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
* Matt Porter mpor...@ti.com [120222 08:13]: This fixes smsc911x support on platforms using gpmc_smsc911x_init(). Commit c7e963f616 (net/smsc911x: Add regulator support) added the requirement that platforms provide vdd33a and vddvario supplies. Signed-off-by: Matt Porter mpor...@ti.com --- Changes for v2: - temporary fix to avoid platform device id conflicts - add commit summary from the smsc911x regulator support commit - incorporate platform device registration error cause reporting Thanks applying into fixes. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] gpio/omap: cleanup and runtime PM conversion for v3.4
On Wed, Feb 22, 2012 at 02:41:05PM -0800, Kevin Hilman wrote: Hi Grant, Any objections to this series? Can we get this queued and into linux-next? I'll have an additional pull request for Benoit's GPIO DT stuff that depends on this for v3.4 too after that series is finalized. The diffstat is clean. I've merged it in. g. Thanks, Kevin On 02/16/2012 12:43 PM, Kevin Hilman wrote: 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
Re: [PATCHv5 03/14] arm: omap3+: voltage: parameter segregation
On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 949938d..940a0d6 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
[...]
@@ -171,6 +169,18 @@ struct omap_voltdm_pmic {
u8 (*uv_to_vsel) (unsigned long uV);
};
+struct omap_vp_param {
+ u32 vddmax;
+ u32 vddmin;
+};
+
Thinking a little deeper about this(SoC level vdd min and max) on a
slightly different angle- core of the question that intend to answer
are:
- what is the least voltage we want to allow in active transtion? it
should not be lower than retention voltage.
- what is the max voltage we want to allow in active transition? it
should be the max Nom voltage of all the OPPs for that domain.
In effect, why do we even need to register
voltdm-vp_param-vdd[min|max]? We already have that info - right?
On the other hand it might be safer to do this way to handle quirks in
future SoCs.. but thought I'd spit it out anyways..
+struct omap_vc_param {
and elsewhere - please add kernel-doc struct documentation as well
when new structs are introduced?
+ u32 on;
+ u32 onlp;
+ u32 ret;
+ u32 off;
+};
+
[...]
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
[PATCH] MFD: TWL 6030: clear IRQ status register only once
TWL6030 family of PMIC use a shadow interrupt status register while kernel processes the current interrupt event. However, any write(0 or 1) to register INT_STS_A, INT_STS_B or INT_STS_C clears all 3 interrupt status registers. Since clear of the interrupt is done on 32k clk, depending on I2C bus speed, we could in-adverently clear the status of a interrupt status pending on shadow register in the current implementation. This is due to the fact that multi-byte i2c write operation into three seperate status register could result in multiple load and clear of status and result in lost interrupts. Instead, doing a single byte write to INT_STS_A register with 0x0 will clear all three interrupt status registers without the related risk. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- drivers/mfd/twl6030-irq.c | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c index c6b456a..aa367a2 100644 --- a/drivers/mfd/twl6030-irq.c +++ b/drivers/mfd/twl6030-irq.c @@ -185,8 +185,17 @@ static int twl6030_irq_thread(void *data) } local_irq_enable(); } - ret = twl_i2c_write(TWL_MODULE_PIH, sts.bytes, - REG_INT_STS_A, 3); /* clear INT_STS_A */ + + /* +* NOTE: +* Simulation confirms that documentation is wrong w.r.t the +* interrupt status clear operation. A single *byte* write to +* any one of STS_A to STS_C register results in all three +* STS registers being reset. Since it does not matter which +* value is written, all three registers are cleared on a +* single byte write, so we just use 0x0 to clear. +*/ + ret = twl_i2c_write_u8(TWL_MODULE_PIH, 0x00, REG_INT_STS_A); if (ret) pr_warning(twl6030: I2C error in clearing PIH ISR\n); -- 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
[PATCH] MFD: TWL 6030: make twl6030_irq_set_wake static
twl6030_irq_set_wake is not used anywhere else in the kernel
except as irq_chip.irq_set_wake. No reason for it to be exported.
Also fixes build warning:
drivers/mfd/twl6030-irq.c:230:5: warning: symbol 'twl6030_irq_set_wake' was not
declared. Should it be static?
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/mfd/twl6030-irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index aa367a2..3c2cc00 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -236,7 +236,7 @@ static inline void activate_irq(int irq)
#endif
}
-int twl6030_irq_set_wake(struct irq_data *d, unsigned int on)
+static int twl6030_irq_set_wake(struct irq_data *d, unsigned int on)
{
if (on)
atomic_inc(twl6030_wakeirqs);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] OMAP PM EMU fix for v3.3
Hello Gowda, A few questions... On Wed, 22 Feb 2012, madhusudhan.go...@elektrobit.com wrote: I have tested this on beagle board as well as on OMAP3630 based propriatory phone using SDTI serial trace interface. What driver are you using for SDTI? Does it use pm_runtime* or call clk_enable() on some clock when it is in use? Are you defining a hwmod for it? I don't see an SDTI driver in mainline, but maybe I am just missing it. If it's not there, could you please post it or post a link to it so we can take a look at what it's doing? Also you can test it by just observing the CM_EMU (48005100) clkstctrl register 48 = 0001 Across MPU OFF alone [root@beagleboard /]# echo 0 /sys/kernel/debug/pm_debug/neon_pwrdm/suspend [root@beagleboard /]# echo 0 /sys/kernel/debug/pm_debug/mpu_pwrdm/suspend [root@beagleboard /]# echo 1 /sys/kernel/debug/pm_debug/core_pwrdm/suspend [root@beagleboard /]# echo 1 /sys/kernel/debug/pm_debug/per_pwrdm/suspend [root@beagleboard /]# echo mem /sys/power/state [ 59.694671] PM: Syncing filesystems ... done. [ 59.758209] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 59.789947] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 59.820709] Suspending console(s) (use no_console_suspend to debug) [ 60.055816] PM: suspend of devices complete after 212.493 msecs [ 60.059661] PM: late suspend of devices complete after 3.784 msecs [ 60.059753] Disabling non-boot CPUs ... [ 64.299865] Successfully put all powerdomains to target state [ 64.302551] PM: early resume of devices complete after 2.319 msecs [ 64.636444] PM: resume of devices complete after 332.336 msecs [ 64.688446] Restarting tasks ... done. [root@beagleboard /]# And then print again the CM_EMU (48005100) clkstctrl register offset 48 this will have the reset value and PRM_EMU (48307100) offset e4 = 0100 register confirms the domain wakeup reset from OFF. At this moment the SDTI serial trace interface looses connection. With my patch applied the CM_EMU (48005100) clkstctrl register restores it initial setting across MPU OFF. Maybe you can walk through these thoughts with me and see if it makes sense to you. When the PM code initializes, it will put the EMU clockdomain to software-supervised sleep. (Ideally it would put it to hardware-supervised idle, but Jouni turned this off a long time ago, apparently due to some PRCM usecounting problem with it -- which may simply have been some software problem on our part?) That accounts for CM_CLKSTCTRL_EMU being set to 0x1 before MPU OFF. Does the SDTI work for you when CM_CLKSTCTRL_EMU is set to 0x1? There's no FCLKEN/ICLKEN bit for the PRCM to use-count, it seems :-( Although maybe this is done through the SDTI_WINCTRL register? I observe the same phenomenon that you do, that when MPU comes back from OFF, CM_CLKSTCTRL_EMU is set to 0x2. From reading the TRM, it's not clear to me what is causing that, although I'd agree with your conclusion that it's related to the MPU's reset line. But here's the part that's unclear to me about your description: according to the TRM, 0x2 means software-supervised wakeup. So the EMU clockdomain should be awake at that point. That shouldn't prevent the SDTI from working; in fact quite the opposite. So I don't really understand how your patch would fix anything in this regard. Any thoughts? My suspicion, by the way, is that the underlying problem may be with the SDTI driver that you're using. My guess would be that it's not integrated with the OMAP power management infrastructure (via pm_runtime* calls), and that's what's causing the problem. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFT 1/1] OMAP2+: cpufreq: scale voltage along with frequency
Hi Kevin, On Thu, Feb 23, 2012 at 00:12:06, Hilman, Kevin wrote: And in my patch plus - minus was not used as regulator framework will try to set voltage for the least voltage which sometimes corresponds to exact OPP required value. sometimes? I was not clear in my previous statement, let me explain it differently. Regulator framework will always try to set lowest voltage in the range. Upon, regulator_set_voltage(reg, OPPVOLT, (OPPVOLT+RESOLUTION-1)), if OPPVOLT is a value that can be set by the regulator, that will be set by the regulator, this is what I meant by 'sometimes'. Otherwise it will set the next possible step. Using your example above, what if the closest value was 1.259V? Wouldn't you then need +/- range? In that case, it will set to next step after 1.259V. If +/- is used, it may happen that SoC will work for a particular frequency at a voltage lower than it has been characterized (if you ask me to define characterized, I don't know, but what I know is that SoC can work at a lower frequency for the voltage of an OPP, but not vice versa). Still as voltage will be only very less than that specified by OPP, it may not be a problem to use +/- Please have a look at my v2. The drivers will get pre and post notifiers, with the caveat that upon DVFS failure, the freq in the post notifier might be the same as the one in the pre notifier, indicating that no change was made. Yes, I overlooked your freq.new update for error condition. Earlier while adding support for DVFS on AM335X, it was noticed that, lpj was going wrong after dvfs failure, then those error notifiers were added to recover properly. Later it was realized that it was due to a bug in cpufreq framework, d08de0c1 [CPUFREQ] update lpj only if frequency has changed fixed it, probably those extra handling in my patch is not required now, if drivers can understand your pre post notifiers properly (if drivers can't, then maybe it is driver problem) Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: fix section mismatch warning for omap4_hotplug_cpu()
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x8b80):
Section mismatch in reference from the function omap4_hotplug_cpu() to
the function .cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references
the function __cpuinit omap_secondary_startup().
This is often because omap4_hotplug_cpu lacks a __cpuinit
annotation or the annotation of omap_secondary_startup is wrong.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 1d5d010..fe9ab7c 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -300,7 +300,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
* @cpu : CPU ID
* @power_state: CPU low power state.
*/
-int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
+int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
{
unsigned int cpu_state = 0;
--
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
[PATCH 0/2] OMAP: Section mismatch warning fixes
Tony, Below are couple of section mismatch warning fixes for v3.3-rc5 Santosh Shilimkar (2): ARM: OMAP: fix section mismatch warning for omap4_hotplug_cpu() ARM: OMAP: Fix section mismatch warning for platform_cpu_die() arch/arm/mach-omap2/omap-hotplug.c|2 +- arch/arm/mach-omap2/omap-mpuss-lowpower.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 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
[PATCH 2/2] ARM: OMAP: Fix section mismatch warning for platform_cpu_die()
WARNING: vmlinux.o(.text+0x226d0):
Section mismatch in reference from the function
platform_cpu_die() to the function .cpuinit.text:omap4_hotplug_cpu()
The function platform_cpu_die() references
the function __cpuinit omap4_hotplug_cpu().
This is often because platform_cpu_die lacks a __cpuinit
annotation or the annotation of omap4_hotplug_cpu is wrong.
Thanks to Russell King for suggesting __ref annotation trick
just like it's parent function for this warning becasue __cupinit
usage was definitely wrong to fix this warning..
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-hotplug.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-hotplug.c
b/arch/arm/mach-omap2/omap-hotplug.c
index adbe4d8..56c345b 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -33,7 +33,7 @@ int platform_cpu_kill(unsigned int cpu)
* platform-specific code to shutdown a CPU
* Called with IRQs disabled
*/
-void platform_cpu_die(unsigned int cpu)
+void __ref platform_cpu_die(unsigned int cpu)
{
unsigned int this_cpu;
--
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
RE: [PATCH/RFT 1/1] OMAP2+: cpufreq: scale voltage along with frequency
Hi Kevin, On Thu, Feb 23, 2012 at 10:58:57, Mohammed, Afzal wrote: Using your example above, what if the closest value was 1.259V? Wouldn't you then need +/- range? In that case, it will set to next step after 1.259V. If +/- is used, it may happen that SoC will work for a particular frequency at a voltage lower than it has been characterized (if you ask me to define characterized, I don't know, but what I know is that SoC can work at a lower frequency for the voltage of an OPP, but not vice versa). Still as voltage will be only very less than that specified by OPP, it may not be a problem to use +/- Upon discussing with Sekhar, realized that I was wrong in the above statements, +/- OPP tolerance range should be used. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP PM constraint to disable OPP50
Hi, This is an old issue, and I've mentioned earlier, but I think we should finally do something about this. Or perhaps this can already be done, but I don't know the solution. The problem is that various DSS clocks have max frequencies that depend on whether we are at OPP100 or OPP50 (e.g. table 10-4. DSS Clock Frequencies in OMAP4 TRM). Some of these clocks come from the PRCM (like DSS_CLK on OMAP4), but some are generated internally by DSS (like pixel clocks). While the clocks coming from PRCM could perhaps be handled automatically (from DSS's point of view) by the PM/clock framework so that OPP50 would be disabled if the clocks are over the OPP50-limit, I guess that's not quite correct. The max freq limitation is inside DSS HW, not in the PRCM side (well, I'm guessing so). And as we anyway need to handle some of the clock limits inside DSS, I guess it's simpler to handle them all in DSS. But the main question is, how should it be done? Afaik the dss driver cannot say stay in OPP100 to the PM framework. I guess the closest thing is to set a constraint to memory throughput with an arbitrarily high value, thus forcing OPP100. But even if it's quite easy to come up with an arbitrary value that should be high enough for years to come, this approach feels rather hacky. Can it have side effects? May it cause overclocking, as the PM framework thinks we need as much bandwidth as possible? Does it cause higher power consumption because something in L3/Core/somewhere is kept in a high perf mode for the high mem throughput, even if we don't actually need high throughput? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] OMAP4: dma: Correct CPU version check for dma_common_ch_end
Hi Tony, On 02/23/2012 01:07 AM, Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@ti.com [120217 00:54]: CCDN is the last common channel register in all OMAP4 versions. Use cpu_is_omap44xx() instead of the cpu_is_omap4430() - which is anyway not doing what it supposed to do. This is a bit unclear.. Which is not doing what is supposed to do? DMA driver? Or one of the cpu_is_omap? The cpu_is_omap4430() returns 0 unconditionally. Because of this the dma_common_ch_end is wrongly configured on OMAP4 (even on OMAP4430). If this should be queued as a fix, then we need some kind of description here what breaks. I will resend the patch with a better commit message. This is a bug for sure, but I'm not sure how severe it is. At best we are not clearing the registers between CCFN, and CCDN on OMAP4. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAP4: dma: Correct CPU version check for dma_common_ch_end
CCDN is the last common channel register in all OMAP4 versions. Use cpu_is_omap44xx() instead of the cpu_is_omap4430(). cpu_is_omap4430() returns 0 unconditionally. This causes that the dma_common_ch_end register variable is not configured correctly on OMAP4, not even for OMAP4430. Because of this, registers between CCFN - CCDN will be not cleard in the omap2_clear_dma function in OMAP4. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-omap2/dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c index a59a45a..b19d849 100644 --- a/arch/arm/mach-omap2/dma.c +++ b/arch/arm/mach-omap2/dma.c @@ -227,7 +227,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused) dma_stride = OMAP2_DMA_STRIDE; dma_common_ch_start = CSDP; - if (cpu_is_omap3630() || cpu_is_omap4430()) + if (cpu_is_omap3630() || cpu_is_omap44xx()) dma_common_ch_end = CCDN; else dma_common_ch_end = CCFN; -- 1.7.8.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: [PATCH 2/2] ARM: OMAP: Fix section mismatch warning for platform_cpu_die()
Hello, On Thu, Feb 23, 2012 at 12:28:30PM +0530, Santosh Shilimkar wrote: WARNING: vmlinux.o(.text+0x226d0): Section mismatch in reference from the function platform_cpu_die() to the function .cpuinit.text:omap4_hotplug_cpu() The function platform_cpu_die() references the function __cpuinit omap4_hotplug_cpu(). This is often because platform_cpu_die lacks a __cpuinit annotation or the annotation of omap4_hotplug_cpu is wrong. Thanks to Russell King for suggesting __ref annotation trick just like it's parent function for this warning becasue __cupinit s/it's/its/; s/becasue/because/; s/cup/cpu/ Having said that I think the grammar is broken, too. Maybe: Thanks to Russell King for suggesting to use __ref instead of the initial (and wrong) approach to use __cpuinit. (But note I'm not a native speaker, too) Uwe usage was definitely wrong to fix this warning.. -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
