SDIO card for wifi
Hi, I am planning to have network functionality on beagle board. I want it to connect to wireless network through SDIO interface. Can someone here tell me which SDIO card to use? I mean for which the driver is available in the omap kernel? Regards, Kalpesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Saturday, April 18, 2009 9:24 PM To: Hiremath, Vaibhav Cc: linux-me...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. [Hiremath, Vaibhav] Agreed, and you will also find implementation of driver aligned to this which I have shared with you. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/davinci offer (and preferably also for similar devices by other manufacturers). [Hiremath, Vaibhav] Hans, Can we have IRC session for this? We will discuss this in detail and try to get closure on it. Again I would request you to join me and mauro on IRC chat, I will be staying online tomorrow. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C6400X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. Cheers, Nate On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: Thanks, Vaibhav Hiremath -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Dongsoo Kim Sent: Sunday, April 19, 2009 12:06 PM To: Hans Verkuil Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. [Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify the configuration part of it? What all configuration is exported to the user? But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) [Hiremath, Vaibhav] I have also implemented the driver is the same way and also working with Hans to get it reviewed. But there are some configuration like coeff., luma enhancement, etc... need to export to the user, where we need to add mechanism in V4L2 framework. Since we have one more device where we are demanding for M-to-M operation, I think it is important to go through it. Can you share some documents of your IP for better understanding. Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Thanks for the link, I will go though it and get back to you. Cheers, Nate On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: Thanks, Vaibhav Hiremath -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Dongsoo Kim Sent: Sunday, April 19, 2009 12:06 PM To: Hans Verkuil Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. [Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify the configuration part of it? What all configuration is exported to the user? But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) [Hiremath, Vaibhav] I have also implemented the driver is the same way and also working with Hans to get it reviewed. But there are some configuration like coeff., luma enhancement, etc... need to export to the user, where we need to add mechanism in V4L2 framework. Since we have one more device where we are demanding for M-to-M operation, I think it is important to go through it. Can you share some documents of your IP for better understanding. Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user
[PATCH] twl4030: Add some error checking to twl4030 init
Check for return values of i2c read/write operations and size of scripts being
uploaded to TWL4030
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
drivers/mfd/twl4030-core.c |2 +-
drivers/mfd/twl4030-power.c | 52 +++---
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 769b34b..067b02e 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -358,7 +358,7 @@ EXPORT_SYMBOL(twl4030_i2c_read);
int twl4030_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
{
- /* 2 bytes offset 1 contains the data offset 0 is used by i2c_write */
+ /* 2 bytes: offset 1 contains the data, offset 0 is used by i2c_write */
u8 temp_buffer[2] = { 0 };
/* offset 1 contains the data */
temp_buffer[1] = value;
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 9dc493b..8f5d149 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -257,36 +257,40 @@ static int __init config_warmreset_sequence(u8 address)
return err;
}
-void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+static int __init twl4030_configure_resource(struct twl4030_resconfig *rconfig)
{
int rconfig_addr;
+ int err;
u8 type;
if (rconfig-resource NUM_OF_RESOURCES) {
printk(KERN_ERR
TWL4030 Resource %d does not exist\n,
rconfig-resource);
- return;
+ return -EINVAL;
}
rconfig_addr = res_config_addrs[rconfig-resource];
/* Set resource group */
-
if (rconfig-devgroup = 0)
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
rconfig-devgroup 5,
rconfig_addr + DEVGROUP_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR
+ TWL4030 failed to program devgroup);
+ return err;
+ }
/* Set resource types */
-
- if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
- type,
- rconfig_addr + TYPE_OFFSET) 0) {
+ err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, type,
+ rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
printk(KERN_ERR
- TWL4030 Resource %d type could not read\n,
- rconfig-resource);
- return;
+ TWL4030 Resource %d type could not be read\n,
+ rconfig-resource);
+ return err;
}
if (rconfig-type = 0) {
@@ -299,8 +303,15 @@ void twl4030_configure_resource(struct twl4030_resconfig
*rconfig)
type |= rconfig-type2 3;
}
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
type, rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR
+ TWL4030 failed to program resource type);
+ return err;
+ }
+
+ return 0;
}
@@ -309,6 +320,12 @@ static int __init load_triton_script(struct twl4030_script
*tscript)
u8 address = triton_next_free_address;
int err;
+ /* Make sure the script isn't going beyond last valid address */
+ if ((address + tscript-size) (END_OF_SCRIPT-1)) {
+ printk(KERN_ERR TWL4030 script too big error\n);
+ return -EINVAL;
+ }
+
err = twl4030_write_script(address, tscript-script, tscript-size);
if (err)
return err;
@@ -346,15 +363,22 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
for (i = 0; i triton2_scripts-size; i++) {
err = load_triton_script(triton2_scripts-scripts[i]);
- if (err)
+ if (err 0) {
+ printk(KERN_ERR TWL4030 failed to load scripts);
break;
+ }
}
resconfig = triton2_scripts-resource_config;
if (resconfig) {
while (resconfig-resource) {
- twl4030_configure_resource(resconfig);
+ err = twl4030_configure_resource(resconfig);
resconfig++;
+ if (err 0) {
+ printk(KERN_ERR
+ TWL4030 failed to configure resource);
+ break;
+ }
}
}
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
RE: [PATCH] [DSPBRIDGE] Various compile warning fixes
Miku,
The field in question is declared in
arch/arm/plat-omap/include/dspbridge/_chnl_sm.h in line 120 as
u32, so checking for negative value makes no sense unless you
modify struct SHM too.
-- You are right. I missed checking the declaration in _chnl_sm.h
Thank you,
Best regards,
Hari
-Original Message-
From: mika.kukko...@nokia.com [mailto:mika.kukko...@nokia.com]
Sent: Monday, April 20, 2009 12:23 AM
To: Kanigeri, Hari; Gupta, Ramesh; ameya.pala...@nokia.com
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH] [DSPBRIDGE] Various compile warning fixes
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
Kanigeri, Hari
Sent: 17 April, 2009 17:21
To: Gupta, Ramesh; Palande Ameya (Nokia-D/Helsinki);
linux-omap@vger.kernel.org
Subject: RE: [PATCH] [DSPBRIDGE] Various compile warning fixes
Ameya,
-if (!(chnlId = 0) || !(chnlId CHNL_MAXCHANNELS)) {
+if (chnlId = CHNL_MAXCHANNELS) {
-- How about declaring chnlId as s32 so that the checks can be
extended to negative values too ?
The field in question is declared in
arch/arm/plat-omap/include/dspbridge/_chnl_sm.h in line 120 as
u32, so checking for negative value makes no sense unless you
modify struct SHM too.
--MiKu
--
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: ehci problem on OMAP35xx
On Wed, Apr 15, 2009 at 9:34 PM, twebb taliaferr...@gmail.com wrote: I'm having issues getting USB up and going on HSUSB2/EHCI on OMAP35xx-based hardware (very similar to beagle board). We're using an SMSC3317 connected to HSUSB2, and in turn, the 3317 is connected to an onboard hub - a SMSC USB2513. When the hub is removed from reset, it appears that handshaking/chirping starts to happen between xcvr and hub, but ends with the code announcing that it is unable to enumerate USB device on port 2. I'm guessing it's failing because we never see PED set in the PORTSC_1 reg (and we are seeing PO=1 which doesn't make any sense). Is the driver chirping properly? Is it identifying the speed properly? I had a similar problem. Please check the D+ and D- line for loading. I used SMSC3320 which also had similar problems because of ESD protection thermistors placed in the board. I'm running a l-o git-based 2.6.28-omap1 kernel with omap3_beagle_defconfig. Beagle board works fine (with patch to ehci-omap.c and with CONFIG_USB_EHCI_HCD turned on), but my hardware (with virtually same xcvr and and onboard hub) does not. Kind of new to this low level USB functionality, so a few questions... 1. Any ideas why we'd see PORTSC_1[PO] = 1? 2. Any suggestions on debugging basic connectivity between 35xx EHCI controller and transceiver + hub? Thanks, twebb -- 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 00/02] OMAP3 clock: Remove virtual clock nodes
Nayak, Rajendra rna...@ti.com writes: Resending this patch-set with some issues of tabs-to-spaces reported by Kevin Hilman fixed and also some warning removals from Jean Pihet. Patches apply on latest linux-omap pm branch + [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver sent on 04/15/09 http://marc.info/?l=linux-omapm=123980012121460w=2 Thanks, pushing this whitespace-fixed version of series to PM branch today. Kevin This patch set removes the virtual clock node implementation for VDD1/2 on omap3 which was causing issues with recursive locking of spinlocks. All references to virtual clock nodes from resource framework and cpufreq driver are removed. Resource framework now uses individual dpll clock nodes to do frequency scaling. Most of the functionality implemented as part of the virtual clock nodes is now implemented internally in the resource framework. Thanks to Tero Kristo tero.kri...@nokia.com who has implemented most of these changes. regards, Rajendra -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: n800 build error in clock24xx.c: 'secure_32k_ck' undeclared
* green greenfreedo...@gmail.com [090419 18:43]: Kalle Valo wrote at 2009-04-19 09:58 -0600: green greenfreedo...@gmail.com writes: Kalle Valo wrote at 2009-04-17 14:44 -0600: arch/arm/kernel/sys_oabi-compat.c: In function 'sys_oabi_epoll_wait': arch/arm/kernel/sys_oabi-compat.c:289: error: implicit declaration of function 'kmalloc' arch/arm/kernel/sys_oabi-compat.c:289: warning: assignment makes pointer from integer without a cast arch/arm/kernel/sys_oabi-compat.c:302: error: implicit declaration of function 'kfree' arch/arm/kernel/sys_oabi-compat.c: In function 'sys_oabi_semtimedop': arch/arm/kernel/sys_oabi-compat.c:325: warning: assignment makes pointer from integer without a cast I see nearly the same: arch/arm/kernel/sys_oabi-compat.c: In function ‘sys_oabi_epoll_wait’: arch/arm/kernel/sys_oabi-compat.c:288: error: implicit declaration of function ‘kmalloc’ arch/arm/kernel/sys_oabi-compat.c:288: error: ‘GFP_KERNEL’ undeclared (first use in this function) I think that's the same error. Most probably my tree was dirty and that's the line numbers are different. I was noticing the 'GFP_KERNEL' undeclared error rather than the line numbers. Looks like the above is fixed by cbb55092a674bcfd9774637a06d0f1511763aa2c, I'll git cherry-pick that one. The secure_32k_ck is still undefined though. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: n800 build error in clock24xx.c: 'secure_32k_ck' undeclared
Hi Kalle, On Fri, 17 Apr 2009, Kalle Valo wrote: In file included from arch/arm/mach-omap2/clock24xx.c:46: arch/arm/mach-omap2/clock24xx.h:1801: error: 'secure_32k_ck' undeclared here (not in a function) Any hints? This is a bug in the version of fa9ef57a1efdd4e7c41a42db71d99b9b69e9b356 I pushed. The new clock definition in clock24xx.h for secure_32k_fck should be for secure_32k_ck. Just talked with Tony about this; he's going to re-pull a fixed version of that patch today. Thanks for the find, - 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
RFC for supporting multiple PMICs
All,
Based on our understanding/experiences till so far, we suggest the
following:
a) Remove all the PMIC-board related stuff from the EVM specific file (
like board-omap3evm.c) and keep it in a separate file (board-omap3evm-
pmic.c). All platform related Inits should be done here.
b) PMIC initialization and other PMIC specific routines (enable/disable,
get/set voltage/current) should be done in the PMIC specific file like
drivers/regulator/pmic.c
c) Probing for PMIC during runtime could be done in either of the ways
specified in the attached sample template.
d) Generic wrappers should be provided to have a consistent interface
for accessing PMIC registers and to use its supported features.
Please find attached the sample implementation of the things mentioned
above and provide your feedback.
Thanks and Regards,
Anuj Aggarwal
Platform Support Products
Texas Instruments Incorporated
/*
* linux/arch/arm/mach-omap2/board-omap3evm-pmic.c
*
* Copyright (C) 2009 Texas Instruments Incorporated
*
* tbd copyright
*/
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
#include linux/i2c/twl4030.h
#include linux/i2c/tps6535x.h
/* --- other generic headers --- */
/*
*
* If we are okay with controlled ifdef in this file then we can follow
* the scheme below...
*
*/
#ifdef CONFIG_TWL4030_CORE
/*
* Definitions specific to TWL4030
*/
#endif /* CONFIG_TWL4030_CORE */
#ifdef CONFIG_PMIC_TPS62350
/*
* Definitions specific to TPS62350
*/
#endif /* CONFIG_PMIC_TPS62350 */
#ifdef CONFIG_PMIC_TPS65023
/*
* Definitions specific to TPS65023
*/
#endif /* CONFIG_PMIC_TPS65023 */
int omap3_evm_pmic_init()
{
#ifdef CONFIG_TWL4030_CORE
/* do stuff specific to TWL4030 */
#elif CONFIG_PMIC_TPS62350
/* do stuff specific to TPS62350 */
#elif CONFIG_PMIC_TPS65023
/* do stuff specific to TPS65023 */
#endif
}
/* =
*
* If we would like to run same image on multiple OMAP3EVMs and don't really
* care about the image size, then we can follow the scheme below...
*
* Though there is still an open question of how to detect PMIC at runtime?
* =
*/
/*
* Definitions specific to TWL4030
*/
/*
* Definitions specific to TPS62350
*/
/*
* Definitions specific to TPS65023
*/
static int flag_pmic_twl4030 = 0;
static int flag_pmic_tps6235x = 0;
static int flag_pmic_tps65023 = 0;
/*
* Detect the current PMIC
* Set one of the flags
*/
static inline int detect_pmic()
{
/* How? Any suggestions?? */
}
static inline int use_pmic_twl4030()
{
return flag_pmic_twl4030;
}
static inline int use_pmic_tps6235x()
{
return flag_pmic_tps6235x;
}
static inline int use_pmic_tps65023()
{
return flag_pmic_tps65023;
}
int omap3_evm_pmic_init()
{
if (use_pmic_twl4030())
{
/* do stuff specific to TWL4030 */
}
else if (use_pmic_tps6235x())
{
/* do stuff specific to TPS62350 */
}
else if (use_pmic_tps65023())
{
/* do stuff specific to TPS65023 */
}
}
/*
*
* Generic wrappers to access PMIC registers and use its supported features...
*
*/
int omap3_pmic_i2c_read()
{
/* Approach 1 */
#ifdef CONFIG_TWL4030_CORE
/* do stuff specific to TWL4030 */
#elif CONFIG_PMIC_TPS62350
/* do stuff specific to TPS62350 */
#elif CONFIG_PMIC_TPS65023
/* do stuff specific to TPS65023 */
#endif
/* Approach 2 */
if (use_pmic_twl4030())
{
/* do stuff specific to TWL4030 */
}
else if (use_pmic_tps6235x())
{
/* do stuff specific to TPS62350 */
}
else if (use_pmic_tps65023())
{
/* do stuff specific to TPS65023 */
}
}
int omap3_pmic_i2c_write()
{
/* just for illustration */
}
int omap3_evm_enable_lcd()
{
/* just for illustration */
}
int omap3_evm_disable_lcd()
{
/* just for illustration */
}
int omap3_evm_enable_dvi()
{
/* just for illustration */
}
int omap3_evm_disable_dvi()
{
/* just for illustration */
}
int omap3_evm_enable_tv()
{
/* just for illustration */
}
int omap3_evm_disable_tv()
{
/* just for illustration */
}
Re: n800 build error in clock24xx.c: 'secure_32k_ck' undeclared
On Mon, 20 Apr 2009, Paul Walmsley wrote:
On Fri, 17 Apr 2009, Kalle Valo wrote:
In file included from arch/arm/mach-omap2/clock24xx.c:46:
arch/arm/mach-omap2/clock24xx.h:1801: error: 'secure_32k_ck' undeclared
here (not in a function)
Any hints?
This is a bug in the version of fa9ef57a1efdd4e7c41a42db71d99b9b69e9b356 I
pushed. The new clock definition in clock24xx.h for secure_32k_fck
should be for secure_32k_ck. Just talked with Tony about this; he's
going to re-pull a fixed version of that patch today.
Here's the patch BTW:
- Paul
Index: linux-omap-2.6/arch/arm/mach-omap2/clock24xx.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/clock24xx.h 2009-04-20
10:42:21.0 -0700
+++ linux-omap-2.6/arch/arm/mach-omap2/clock24xx.h 2009-04-20
10:46:09.0 -0700
@@ -625,8 +625,8 @@ static struct clk func_32k_ck = {
.clkdm_name = wkup_clkdm,
};
-static struct clk secure_32k_fck = {
- .name = secure_32k_fck,
+static struct clk secure_32k_ck = {
+ .name = secure_32k_ck,
.ops= clkops_null,
.rate = 32768,
.flags = RATE_FIXED,
--
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
[APPLIED] n800 build error in clock24xx.c: #39;secure_32k_ck#39; undeclared
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): dc1ac9cea15e3317badd0fdece931926413f6759 PatchWorks http://patchwork.kernel.org/patch/19037/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=dc1ac9cea15e3317badd0fdece931926413f6759 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
On Monday 20 April 2009 12:31:53 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Saturday, April 18, 2009 9:24 PM To: Hiremath, Vaibhav Cc: linux-me...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. [Hiremath, Vaibhav] Agreed, and you will also find implementation of driver aligned to this which I have shared with you. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/davinci offer (and preferably also for similar devices by other manufacturers). [Hiremath, Vaibhav] Hans, Can we have IRC session for this? We will discuss this in detail and try to get closure on it. Again I would request you to join me and mauro on IRC chat, I will be staying online tomorrow. No problem (assuming we don't have another major network outage as we had today at work). It would be helpful if you could mail a summary of the capabilities that are needed but are not yet in the API. Also note that I have to leave at 16:15 (UTC+2). Magnus, does the SuperH also have resizing/previewer capabilities? And if so, is there a datasheet available with detailed information? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
Compilation Issue with OMAP_SMARTREFLEX, CONFIG_USB_ARCH_HAS_EHCI
Hi, The following set of .config settings: #CONFIG_PM set to OFF CONFIG_USB_ARCH_HAS_EHCI=y triggers the following compile error: ... CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `omap3_sr_init': usb-ehci.c:(.init.text+0xc0c): undefined reference to `power_kobj' make: *** [.tmp_vmlinux1] Error 1 When EHCI is turned off, the error becomes: arch/arm/mach-omap2/built-in.o: In function `omap3_sr_init': board-omap3evm-flash.c:(.init.text+0xc0c): undefined reference to `power_kobj' make: *** [.tmp_vmlinux1] Error 1 Error disappears when Smart reflex is turned off: #OMAP_SMARTREFLEX set to OFF Than the kernel compiles OK. -dmt -- 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
[no subject]
subscribe -- 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
LDP broken in 2.6.30-rc 2
Hi, I cloned master a few days ago and when I boot up the OMAP3 LDP, the board seem to hang in the i2c /dev entries driver dialog and after a minute the kernel dumps. Have anybody else seen this problem? Log is below. Best regards, Mikkel Bytes transferred = 1851164 (1c3f1c hex) ## Booting image at 8000 ... Image Name: Linux-2.6.30-rc2-omap1-05648-g8e Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1851100 Bytes = 1.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... 5Linux version 2.6.30-rc2-omap1-05648-g8e58316-dirty (a0389...@a0389005-desktop) (gcc version 4.2.3 (Sourcery G++ Lite 20089 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP LDP board Memory policy: ECC disabled, Data cache writeback 7On node 0 totalpages: 28672 7free_area_init_node: node 0, pgdat c0391ac8, node_mem_map c03ad000 7 Normal zone: 224 pages used for memmap 7 Normal zone: 0 pages reserved 7 Normal zone: 28448 pages, LIFO batch:7 6OMAP3430 ES2.1 6SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 28448 5Kernel command line: console=ttyS2,115200n8 noinitrd mem=112M root=/dev/nfs rw nfsroot=128.247.85.60:/home/a0389051/omap34p 6NR_IRQS:402 6Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz 6GPMC revision 5.0 6IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts 6Total of 96 interrupts on 1 active controller 6OMAP34xx GPIO hardware version 2.5 PID hash table entries: 512 (order: 9, 2048 bytes) 6OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 6Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) 6Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) 6Memory: 112MB = 112MB total 5Memory: 109780KB available (3176K code, 292K data, 144K init, 0K highmem) 6Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696) Mount-cache hash table entries: 512 6CPU: Testing write buffer coherency: ok 6net_namespace: 520 bytes 6regulator: core version 0.5 6NET: Registered protocol family 16 3mmci-omap-hs.0: use which platform_data? 6OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 6i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz 6twl4030: PIH (irq 7) chaining IRQs 368..375 6twl4030: power (irq 373) chaining IRQs 376..383 3twl4030_bci: use which platform_data? 3twl4030_gpio: use which platform_data? 6twl4030: gpio (irq 368) chaining IRQs 384..401 3twl4030_keypad: use which platform_data? 3twl4030_madc: use which platform_data? 3twl4030_usb: use which platform_data? 3twl4030_reg.17: use which platform_data? 3set_machine_constraints: invalid 'VUSB1V5' voltage constraints 3twl4030_reg twl4030_reg.17: can't register VUSB1V5, -22 4twl4030_reg: probe of twl4030_reg.17 failed with error -22 3twl4030_reg.18: use which platform_data? 3set_machine_constraints: invalid 'VUSB1V8' voltage constraints 3twl4030_reg twl4030_reg.18: can't register VUSB1V8, -22 4twl4030_reg: probe of twl4030_reg.18 failed with error -22 3twl4030_reg.19: use which platform_data? 3set_machine_constraints: invalid 'VUSB3V1' voltage constraints 3twl4030_reg twl4030_reg.19: can't register VUSB3V1, -22 4twl4030_reg: probe of twl4030_reg.19 failed with error -22 6i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz 6i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz 5SCSI subsystem initialized 3twl4030_usb twl4030_usb: ldo init failed 6usbcore: registered new interface driver usbfs 6usbcore: registered new interface driver hub 6usbcore: registered new device driver usb 6musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 7Switched to high resolution mode on CPU 0 7musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO Rx (X)) 7musb_hdrc: MHDRC RTL version 1.400 7musb_hdrc: setup fifo_mode 4 7musb_hdrc: 29/31 max ep, 15424/16384 memory 7musb_hdrc: hw_ep 0shared, max 64 7musb_hdrc: hw_ep 1tx, max 512 7musb_hdrc: hw_ep 1rx, max 512 7musb_hdrc: hw_ep 2tx, max 512 7musb_hdrc: hw_ep 2rx, max 512 7musb_hdrc: hw_ep 3tx, max 512 7musb_hdrc: hw_ep 3rx, max 512 7musb_hdrc: hw_ep 4tx, max 512 7musb_hdrc: hw_ep 4rx, max 512 7musb_hdrc: hw_ep 5tx, max 512 7musb_hdrc: hw_ep 5rx, max 512 7musb_hdrc: hw_ep 6tx, max 512 7musb_hdrc: hw_ep 6rx, max 512 7musb_hdrc: hw_ep 7tx, max 512 7musb_hdrc: hw_ep 7rx, max 512 7musb_hdrc: hw_ep 8tx, max 512 7musb_hdrc: hw_ep 8rx, max 512 7musb_hdrc: hw_ep 9tx, max 512 7musb_hdrc: hw_ep 9rx, max 512 7musb_hdrc: hw_ep 10tx, max 512 7musb_hdrc: hw_ep 10rx, max 512 7musb_hdrc: hw_ep 11tx, max 512 7musb_hdrc: hw_ep 11rx, max 512 7musb_hdrc: hw_ep 12tx, max 512 7musb_hdrc: hw_ep
RE: [PATCH] twl4030: Add some error checking to twl4030 init
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Amit Kucheria
Sent: Monday, April 20, 2009 6:20 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH] twl4030: Add some error checking to twl4030 init
Check for return values of i2c read/write operations and size
of scripts being
uploaded to TWL4030
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
[sp] You may want to fix the leading whitespaces in some places.
see few instanes below.
Otherwise, looks pretty straight.
---
drivers/mfd/twl4030-core.c |2 +-
drivers/mfd/twl4030-power.c | 52
+++---
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 769b34b..067b02e 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -358,7 +358,7 @@ EXPORT_SYMBOL(twl4030_i2c_read);
int twl4030_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
{
- /* 2 bytes offset 1 contains the data offset 0 is used
by i2c_write */
+ /* 2 bytes: offset 1 contains the data, offset 0 is
used by i2c_write */
u8 temp_buffer[2] = { 0 };
/* offset 1 contains the data */
temp_buffer[1] = value;
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 9dc493b..8f5d149 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -257,36 +257,40 @@ static int __init
config_warmreset_sequence(u8 address)
return err;
}
-void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+static int __init twl4030_configure_resource(struct
twl4030_resconfig *rconfig)
{
int rconfig_addr;
+ int err;
u8 type;
if (rconfig-resource NUM_OF_RESOURCES) {
printk(KERN_ERR
TWL4030 Resource %d does not exist\n,
rconfig-resource);
- return;
+ return -EINVAL;
}
rconfig_addr = res_config_addrs[rconfig-resource];
/* Set resource group */
-
if (rconfig-devgroup = 0)
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
rconfig-devgroup 5,
rconfig_addr + DEVGROUP_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR
+TWL4030 failed to program devgroup);
[sp] ...here...
+ return err;
+ }
/* Set resource types */
-
- if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
- type,
- rconfig_addr +
TYPE_OFFSET) 0) {
+ err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, type,
+ rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
printk(KERN_ERR
- TWL4030 Resource %d type could not read\n,
- rconfig-resource);
- return;
+TWL4030 Resource %d type could not be read\n,
+rconfig-resource);
[sp] ...here...
+ return err;
}
if (rconfig-type = 0) {
@@ -299,8 +303,15 @@ void twl4030_configure_resource(struct
twl4030_resconfig *rconfig)
type |= rconfig-type2 3;
}
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
type, rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR
+TWL4030 failed to program resource type);
[sp] ...here...
+ return err;
+ }
+
+ return 0;
}
@@ -309,6 +320,12 @@ static int __init
load_triton_script(struct twl4030_script *tscript)
u8 address = triton_next_free_address;
int err;
+ /* Make sure the script isn't going beyond last valid address */
+ if ((address + tscript-size) (END_OF_SCRIPT-1)) {
+ printk(KERN_ERR TWL4030 script too big error\n);
+ return -EINVAL;
+ }
+
err = twl4030_write_script(address, tscript-script,
tscript-size);
if (err)
return err;
@@ -346,15 +363,22 @@ void __init twl4030_power_init(struct
twl4030_power_data *triton2_scripts)
for (i = 0; i triton2_scripts-size; i++) {
err = load_triton_script(triton2_scripts-scripts[i]);
- if (err)
+ if (err 0) {
+ printk(KERN_ERR TWL4030 failed to load
scripts);
break;
+ }
}
resconfig = triton2_scripts-resource_config;
if (resconfig) {
while (resconfig-resource) {
- twl4030_configure_resource(resconfig);
+
[PATCH] twl4030: Add some error checking to twl4030 init
Whitespace-fixed version and passed through checkpatch.pl
Check for return values of i2c read/write operations and size of scripts being
uploaded to TWL4030
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
drivers/mfd/twl4030-core.c |2 +-
drivers/mfd/twl4030-power.c | 49 ++
2 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 769b34b..067b02e 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -358,7 +358,7 @@ EXPORT_SYMBOL(twl4030_i2c_read);
int twl4030_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
{
- /* 2 bytes offset 1 contains the data offset 0 is used by i2c_write */
+ /* 2 bytes: offset 1 contains the data, offset 0 is used by i2c_write */
u8 temp_buffer[2] = { 0 };
/* offset 1 contains the data */
temp_buffer[1] = value;
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 9dc493b..b4b636d 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -257,36 +257,38 @@ static int __init config_warmreset_sequence(u8 address)
return err;
}
-void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+static int __init twl4030_configure_resource(struct twl4030_resconfig *rconfig)
{
int rconfig_addr;
+ int err;
u8 type;
if (rconfig-resource NUM_OF_RESOURCES) {
printk(KERN_ERR
TWL4030 Resource %d does not exist\n,
rconfig-resource);
- return;
+ return -EINVAL;
}
rconfig_addr = res_config_addrs[rconfig-resource];
/* Set resource group */
-
if (rconfig-devgroup = 0)
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
rconfig-devgroup 5,
rconfig_addr + DEVGROUP_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR TWL4030 failed to program devgroup);
+ return err;
+ }
/* Set resource types */
-
- if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
- type,
- rconfig_addr + TYPE_OFFSET) 0) {
- printk(KERN_ERR
- TWL4030 Resource %d type could not read\n,
+ err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, type,
+ rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR TWL4030 Resource %d type could not be read\n,
rconfig-resource);
- return;
+ return err;
}
if (rconfig-type = 0) {
@@ -299,8 +301,14 @@ void twl4030_configure_resource(struct twl4030_resconfig
*rconfig)
type |= rconfig-type2 3;
}
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
type, rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR TWL4030 failed to program resource type);
+ return err;
+ }
+
+ return 0;
}
@@ -309,6 +317,12 @@ static int __init load_triton_script(struct twl4030_script
*tscript)
u8 address = triton_next_free_address;
int err;
+ /* Make sure the script isn't going beyond last valid address */
+ if ((address + tscript-size) (END_OF_SCRIPT-1)) {
+ printk(KERN_ERR TWL4030 script too big error\n);
+ return -EINVAL;
+ }
+
err = twl4030_write_script(address, tscript-script, tscript-size);
if (err)
return err;
@@ -346,15 +360,22 @@ void __init twl4030_power_init(struct twl4030_power_data
*triton2_scripts)
for (i = 0; i triton2_scripts-size; i++) {
err = load_triton_script(triton2_scripts-scripts[i]);
- if (err)
+ if (err 0) {
+ printk(KERN_ERR TWL4030 failed to load scripts);
break;
+ }
}
resconfig = triton2_scripts-resource_config;
if (resconfig) {
while (resconfig-resource) {
- twl4030_configure_resource(resconfig);
+ err = twl4030_configure_resource(resconfig);
resconfig++;
+ if (err 0) {
+ printk(KERN_ERR
+ TWL4030 failed to configure resource);
+ break;
+ }
}
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCH take 2] PM: OMAP: Fix build with CONFIG_OMAP_PM_NONE set
Roger Quadros ext-roger.quad...@nokia.com writes: From: Roger Quadros ext-roger.quad...@nokia.com Date: Wed, 8 Apr 2009 17:12:43 +0300 Subject: [PATCH] PM: OMAP: Fix build with CONFIG_OMAP_PM_NONE set Removes undefined symbol link errors when CONFIG_OMAP_PM is set. The required symbols are defined in common.c and omap-pm.h Dummy variables mpu_oops, dsp_oops and l3_oops have to be defined because they are used in a number of places It fixes the following link errors arch/arm/mach-omap2/built-in.o: In function `omap3_round_to_table_rate': arch/arm/mach-omap2/clock34xx.c:956: undefined reference to `mpu_opps' arch/arm/mach-omap2/clock34xx.c:956: undefined reference to `dsp_opps' arch/arm/mach-omap2/clock34xx.c:956: undefined reference to `l3_opps' arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_hw': arch/arm/mach-omap2/io.c:241: undefined reference to `omap_pm_if_early_init' arch/arm/mach-omap2/io.c:246: undefined reference to `omap_pm_if_init' make: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com Thanks, pushing to PM branch today. Kevin --- arch/arm/plat-omap/common.c |6 ++ arch/arm/plat-omap/include/mach/omap-pm.h |8 2 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index 2866612..634ca39 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -46,6 +46,12 @@ int omap_bootloader_tag_len; struct omap_board_config_kernel *omap_board_config; int omap_board_config_size; +#ifdef CONFIG_OMAP_PM_NONE +struct omap_opp *mpu_opps; +struct omap_opp *dsp_opps; +struct omap_opp *l3_opps; +#endif + #ifdef CONFIG_OMAP_BOOT_TAG static int __init parse_tag_omap(const struct tag *tag) diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h b/arch/arm/plat-omap/include/mach/omap-pm.h index f0bbd36..5526e89 100644 --- a/arch/arm/plat-omap/include/mach/omap-pm.h +++ b/arch/arm/plat-omap/include/mach/omap-pm.h @@ -58,9 +58,13 @@ extern struct omap_opp *l3_opps; * framework starts. The _if_ is to avoid name collisions with the * PM idle-loop code. */ +#ifdef CONFIG_OMAP_PM_NONE +#define omap_pm_if_early_init(a, b, c) 0 +#else int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table, struct omap_opp *dsp_opp_table, struct omap_opp *l3_opp_table); +#endif /** * omap_pm_if_init - OMAP PM init code called after clock fw init @@ -68,7 +72,11 @@ int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table, * The main initialization code. OPP tables are passed in here. The * _if_ is to avoid name collisions with the PM idle-loop code. */ +#ifdef CONFIG_OMAP_PM_NONE +#define omap_pm_if_init() 0 +#else int __init omap_pm_if_init(void); +#endif /** * omap_pm_if_exit - OMAP PM exit code -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM PATCH] OMAP3: PM: Save and restore I2C wakeup sources
Aaro Koskinen aaro.koski...@nokia.com writes:
Save and restore I2C wakeup sources.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
Sorry for the delay, this one slipped through the cracks.
Pushing to PM branch.
Kevin
---
drivers/i2c/busses/i2c-omap.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 50f3285..5ce055c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -183,6 +183,7 @@ struct omap_i2c_dev {
u16 sclhstate;
u16 bufstate;
u16 syscstate;
+ u16 westate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -242,6 +243,7 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
}
dev-idle = 0;
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
@@ -316,8 +318,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* WFI instruction.
* REVISIT: Some wkup sources might not be needed.
*/
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- OMAP_I2C_WE_ALL);
+ dev-westate = OMAP_I2C_WE_ALL;
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
}
}
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: 2.6.29 and SDP3430
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Mark Brown Sent: Thursday, April 09, 2009 4:34 PM To: Menon, Nishanth Cc: Woodruff, Richard; Jarkko Nikula; linux-omap Subject: Re: 2.6.29 and SDP3430 On Thu, Apr 09, 2009 at 01:32:27PM -0500, Menon, Nishanth wrote: implementor 41 architecture 3 part 30 variant c rev 1 regulator_init_complete: incomplete constraints, leaving VAUX3 on That last message shouldn't be a problem - it means that if the machine init code had requested it the regulator core would've powered off the VAUX3 regulator since it has no users. Well, I just disabled TWL4030 regulator support (CONFIG_REGULATOR_TWL4030) and now it boots without problem... I'm using a SDP3430 VG9.0.0 with an ES3.1 chip. -- 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] OMAP3: PM: Add the wakeup source driver, v3
Kim Kyuwon chamm...@gmail.com writes:
Sometimes, it is necessary to find out what does wake up my board
from suspend?. Notifying wake-up source feature may be used to blame
unexpected wake-up events which increase power consumption. And user
mode applications can act smartly according to the wake-up event from
Suspend-to-RAM state to minimize power consumption. Note that this
driver can't inform wake-up events from idle state. This driver uses
sysfs interface to give information to user mode applications like:
cat /sys/power/omap_resume_irq
cat /sys/power/omap_resume_event
This driver also privides the unified GPIO wake-up source
configuration. specific GPIO settings in the board files are:
/* Wakeup source configuration */
static struct gpio_wake boardname_gpio_wake[] = {
{ 23, IRQF_TRIGGER_RISING,BT_WAKEUP,1},
{ 24, IRQF_TRIGGER_RISING,USB_DETECT, 1},
};
static struct omap_wake_platform_data boardname_wake_data = {
.gpio_wakes = boardname_gpio_wake,
.gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
};
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
The patch adds Kconfig options OMAP34xx wakeup source support under
System type-TI OMAP implementations menu.
Signed-off-by: Kim Kyuwon q1@samsung.com
Hi Kyuwon,
While I still like the concept of this driver, I'm still not quite
happy about how it is implemented for various reasons. Most of which
have to do with the fact that this driver does many things that really
should be the job of other layers. In particular, the list of
omap3_wake_events is a bit troubling. It really should be handled by
the omapdev layer. You'll see that you are duplicating the data that
is handled there. Rather, we should just extend the omapdev data to
handle the wakeup events for that device.
Also, I still think the WKST register reading should be done in the
PRCM interrupt handler. In your previous attempt, you were seeing a
bunch of non-device wakeup related interrupts. Can you try again
with the attached patch (thanks to Paul Walmseley) which should help
us debug why you were seeing spurious PRCM interrupts.
Also, I know we discussed this before, but I think the GPIO wakeup
source stuff really belongs in a separate patch, and if you think it
is still useful, and cannot be done by just enabling a GPIO IRQ from
the board file, I suggest you propose a patch to the generic GPIO
layer to add this interface.
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 21 +-
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h |5 +
arch/arm/mach-omap2/wake34xx.c | 681
arch/arm/plat-omap/Kconfig |9 +
arch/arm/plat-omap/include/mach/irqs.h |4 +
arch/arm/plat-omap/include/mach/wake.h | 30 ++
8 files changed, 752 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e693efd..4d7dbca 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP_WAKE) += wake34xx.o
endif
# SmartReflex driver
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 700fc3d..18ac725 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -33,9 +33,6 @@
#define INTC_MIR_SET00x008c
#define INTC_PENDING_IRQ00x0098
-/* Number of IRQ state bits in each MIR register */
-#define IRQ_BITS_PER_REG 32
-
/*
* OMAP2 has a number of different interrupt controllers, each interrupt
* controller is identified as its own bank. Register definitions are
@@ -193,6 +190,24 @@ int omap_irq_pending(void)
return 0;
}
+void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
+{
+ int i, j = 0;
+
+ for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
+ struct omap_irq_bank *bank = irq_banks + i;
+ int irq;
+
+ for (irq = 0; irq bank-nr_irqs j len;
+ irq += IRQ_BITS_PER_REG) {
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
+
+ pending_irqs[j++] = intc_bank_read_reg(bank,
+ (INTC_PENDING_IRQ0 + offset));
+ }
+ }
+}
+
void
RE: LDP broken in 2.6.30-rc 2
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Christensen, Mikkel
Sent: Monday, April 20, 2009 3:28 PM
To: linux-omap@vger.kernel.org
Subject: LDP broken in 2.6.30-rc 2
Hi,
I cloned master a few days ago and when I boot up the OMAP3 LDP, the board
seem to hang in the i2c
/dev entries driver dialog and after a minute the kernel dumps. Have anybody
else seen this problem?
Log is below.
Best regards,
Mikkel
Here is the crash log after enabling all kernel debugging options on LDP with
master of L-O tree.
Code base: linux-omap master
Platform: LDP
Defconfig: enabled debugging options
[ 97.854797] i2c /dev entries driver
1Unable to handle kernel NULL pointer dereference at virtual address 009b
[ 113.881439] Unable to handle kernel NULL pointer dereference at virtual addre
ss 009b
1pgd = c0004000
[ 113.891387] pgd = c0004000
1[009b] *pgd=[ 113.896545] [009b] *pgd=
Internal error: Oops: 5 [#1]
[ 113.903076] Internal error: Oops: 5 [#1]
Modules linked in:[ 113.908630] Modules linked in:
CPU: 0Not tainted (2.6.30-rc2-omap1-05650-gdc1ac9c-dirty #5)
[ 113.917877] CPU: 0Not tainted (2.6.30-rc2-omap1-05650-gdc1ac9c-dirty #5)
PC is at device_add+0x2d8/0x630
[ 113.928039] PC is at device_add+0x2d8/0x630
LR is at __mutex_unlock_slowpath+0x70/0x10c
[ 113.936279] LR is at __mutex_unlock_slowpath+0x70/0x10c
pc : [c01bdf58]lr : [c02ba844]psr: 2013
sp : c7817e80 ip : c78b8674 fp :
[ 113.950653] pc : [c01bdf58]lr : [c02ba844]psr: 2013
[ 113.950653] sp : c7817e80 ip : c78b8674 fp :
r10: r9 : c7840928 r8 : c7841a60
[ 113.966217] r10: r9 : c7840928 r8 : c7841a60
r7 : c03b8d04 r6 : c7802be0 r5 : c7840920 r4 :
[ 113.976837] r7 : c03b8d04 r6 : c7802be0 r5 : c7840920 r4 :
r3 : 0007 r2 : c7840aa8 r1 : 0007 r0 : c7840aa8
[ 113.988739] r3 : 0007 r2 : c7840aa8 r1 : 0007 r0 : c7840aa8
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 114.001464] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kern
el
Control: 10c5387d Table: 80004019 DAC: 0017
[ 114.013366] Control: 10c5387d Table: 80004019 DAC: 0017
Process swapper (pid: 1, stack limit = 0xc78162e0)
[ 114.023803] Process swapper (pid: 1, stack limit = 0xc78162e0)
Stack: (0xc7817e80 to 0xc7818000)
[ 114.032806] Stack: (0xc7817e80 to 0xc7818000)
7e80: [ 114.037719] 7e80: c785e090 c785e090 3a393800 3a393800
c7840033 c7840033 0021 0021 c784092
0 c7840920
7ea0: [ 114.053222] 7ea0: c7841a60 c7841a60 0593 0593 c785e090 c785e090
c01be36
4 c01be364
7ec0: [ 114.068756] 7ec0: c03570f4 c03570f4 c78513c0 c78513c0 c03c86dc c03c86dc
c785e038 c785e038 c03e1dc0 c03e1dc0 c01be394 c01be394 c03570f4 c03570f4 c7817ef
4 c7817ef4
7ee0: [ 114.084259] 7ee0: c03c86f8 c03c86f8 c7817ef4 c7817ef4 c01ca380 c01ca380
c01c9918 c01c9918 c03570f4 c03570f4 0003 0003 c03c86f8 c03c86f8 c785e03
8 c785e038
7f00: [ 114.099792] 7f00: c03c86f8 c03c86f8 c01c9330 c01c9330 c01ca380 c01ca380
c01c9358 c01c9358 c7817f2c c7817f2c c03c86f8 c03c86f8 c01c0af
4 c01c0af4
7f20: [ 114.115295] 7f20: c03c8584 c03c8584 c03c85c0 c03c85c0 c03c8584 c03c8584
c784b6b0 c784b6b0 c785e114 c785e114 c03c86f
8 c03c86f8
7f40: [ 114.130828] 7f40: c03c8584 c03c8584
c01c8b0c c01c8b0c c03e1dc0 c03e1dc0 c03d0760 c03d0760 c01ca41
0 c01ca410
7f60: [ 114.146331] 7f60: c002391c c002391c c00239ec c00239ec c03d0760 c03d0760
c002e2dc c002e2dc c00e9338 c00e9338 c03d880c c03d880c c033ee2
4 c033ee24
7f80: [ 114.161865] 7f80: 0100 0100 024e 024e c78370a0 c78370a0
c03d880c c03d880c c03b6908 c03b6908 015f 015f c00e958
8 c00e9588
7fa0: [ 114.177368] 7fa0: c007e594 c007e594 c7838680 c7838680 c7817fb6 c7817fb6
c007e5b8 c007e5b8 c7810f60 c7810f60 353339ec 353339ec 0031 0031 000
0
7fc0: [ 114.192901] 7fc0: c002391c c002391c c00239ec c00239ec
c002366c c002366c 000
0
7fe0: [ 114.208404] 7fe0: c0008554 c0008554
c005795c c005795c 107fff11 107fff11 00fbff2
0 00fbff20
[c01bdf58] [ 114.224578] [c01bdf58] (device_add+0x2d8/0x630) (device_add+0x
2d8/0x630) from [c01be364] from [c01be364] (device_create_vargs+0x9c/0xac)
(device_create_vargs+0x9c/0xac)
[c01be364] [ 114.241668] [c01be364] (device_create_vargs+0x9c/0xac) (device
_create_vargs+0x9c/0xac) from [c01be394] from [c01be394] (device_create+0x20
/0x28)
(device_create+0x20/0x28)
[c01be394] [ 114.258941]
[PATCH] DSPBRIDGE: Replacing custom implementation for Mapping
From: Omar Ramirez Luna x0084...@ti.com
Date: Mon, 20 Apr 2009 21:45:46 -0500
Subject: [PATCH] DSPBRIDGE: Replacing custom implementation for Mapping
DSPBRIDGE: Replacing custom implementation for Mapping
Currently, we walk through the entire page table
translating the addresses from virtual to physical
whenever we map a buffer. This custom implementation
is meant to be optimized for performance, but it bypasses
the standard memory management subsystem.
This patch removes the custom implementation and uses
the kernel APIs to get the virtual to physical maps.
Map times for DMM
Buffer | Kernel APIs | Custom Implement. |
Size | time (usec) |time (usec)|
4 KB | 427 |396|
64 KB |1038 |824|
1 MB |9827 | 7110|
4 MB | 37811 | 26916|
6 MB | 56366 | 39978|
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Omar Ramirez Luna x0084...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430.c | 484 +++
1 files changed, 149 insertions(+), 335 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index 208f752..c32ee78 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -1,4 +1,3 @@
-
/*
* tiomap.c
*
@@ -133,9 +132,7 @@ static DSP_STATUS WMD_DEV_Create(OUT struct WMD_DEV_CONTEXT
**ppDevContext,
static DSP_STATUS WMD_DEV_Ctrl(struct WMD_DEV_CONTEXT *pDevContext, u32 dwCmd,
IN OUT void *pArgs);
static DSP_STATUS WMD_DEV_Destroy(struct WMD_DEV_CONTEXT *pDevContext);
-static DSP_STATUS TIOMAP_VirtToPhysical(struct mm_struct *mm, u32 ulMpuAddr,
- u32 ulNumBytes, u32 *numOfTableEntries,
- u32 *physicalAddrTable);
+static u32 user_va2pa(struct mm_struct *mm, u32 address);
static DSP_STATUS PteUpdate(struct WMD_DEV_CONTEXT *hDevContext, u32 pa,
u32 va, u32 size,
struct HW_MMUMapAttrs_t *mapAttrs);
@@ -270,6 +267,21 @@ static inline void flush_all(struct WMD_DEV_CONTEXT
*pDevContext)
tlb_flush_all(pDevContext-dwDSPMmuBase);
}
+void badpagedump(u32 pa, struct page *pg)
+{
+ printk(KERN_EMERG DSPBRIDGE:MAP function: COUNT 0 FOR PA 0x%x\n, pa);
+ printk(KERN_EMERG Bad page state in process '%s'\n
+ page:%p flags:0x%0*lx mapping:%p mapcount:%d count:%d\n
+ Trying to fix it up, but a reboot is needed\n
+ Backtrace:\n,
+ current-comm, pg, (int)(2*sizeof(unsigned long)),
+ (unsigned long)pg-flags, pg-mapping,
+ page_mapcount(pg), page_count(pg));
+ dump_stack();
+ BUG_ON(1);
+
+}
+
/*
* WMD_DRV_Entry
* purpose:
@@ -1352,11 +1364,16 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
DSP_STATUS status = DSP_SOK;
struct WMD_DEV_CONTEXT *pDevContext = hDevContext;
struct HW_MMUMapAttrs_t hwAttrs;
- u32 numOfActualTabEntries = 0;
- u32 *pPhysAddrPageTbl = NULL;
struct vm_area_struct *vma;
struct mm_struct *mm = current-mm;
- u32 temp = 0;
+ u32 write = 0;
+ u32 numUsrPgs = 0;
+ struct page *mappedPage, *pg;
+ s32 pgNum;
+ u32 va = ulVirtAddr;
+ struct task_struct *curr_task = current;
+ u32 pgI = 0;
+ u32 mpuAddr, pa;
DBG_Trace(DBG_ENTER, WMD_BRD_MemMap hDevContext %x, pa %x, va %x,
size %x, ulMapAttr %x\n, hDevContext, ulMpuAddr, ulVirtAddr,
@@ -1424,7 +1441,6 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
* virtual memory address space in order to be of use to us here! */
down_read(mm-mmap_sem);
vma = find_vma(mm, ulMpuAddr);
- up_read(mm-mmap_sem);
if (vma)
DBG_Trace(DBG_LEVEL6, VMAfor UserBuf: ulMpuAddr=%x,
ulNumBytes=%x, vm_start=%x vm_end=%x vm_flags=%x \n,
@@ -1436,9 +1452,7 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
* user buffer is covered */
while ((vma != NULL) (ulMpuAddr + ulNumBytes vma-vm_end)) {
/* jump to the next VMA region */
- down_read(mm-mmap_sem);
vma = find_vma(mm, vma-vm_end + 1);
- up_read(mm-mmap_sem);
DBG_Trace(DBG_LEVEL6, VMAfor UserBuf ulMpuAddr=%x,
ulNumBytes=%x, vm_start=%x vm_end=%x vm_flags=%x\n,
ulMpuAddr, ulNumBytes, vma-vm_start,
@@ -1449,44 +1463,100 @@ static DSP_STATUS WMD_BRD_MemMap(struct
WMD_DEV_CONTEXT *hDevContext,
MPU Buffer !!! \n);
status = DSP_EINVALIDARG;
}
- if (DSP_FAILED(status))
- goto func_cont;
- pPhysAddrPageTbl =
RE: 2.6.29 and SDP3430 now 2.6.30-rc2, q3-2007 compiler error
Thanks Richard for root casing the issue. Yes I also did observed this. Second time when framework calls omap2_gp_timer_set_mode set the periodic mode, R0 contains 0 (CLOCK_EVT_MODE_UNUSED) instead of 2(CLOCK_EVT_MODE_PERIODIC). The assembly generated looks shocking because it prepares the second function arguments in register R1 as expected and then 'pop' destroys it. A push before a function call is reasonable but this not quite understandable. Can this be taken up with Codesorcery team to check what is triggering compiler to generate such an assembly ? -Original Message- From: Woodruff, Richard Sent: Tuesday, April 21, 2009 6:34 AM To: Aguirre Rodriguez, Sergio Alberto; Mark Brown; Menon, Nishanth; Tony Lindgren Cc: Jarkko Nikula; linux-omap; Shilimkar, Santosh; Pandita, Vikram Subject: RE: 2.6.29 and SDP3430 now 2.6.30-rc2, q3-2007 compiler error So using defconfig and float I debugged around a bit and for q3-2007 I see what looks to be compiler error. The parameter in R1 which sets PERIODIC mode for call to clockevnet_set_mode()is destroyed. See PNG. I did make sure at start_kernel the correct opcode was in place (no overwrite later, no cache flush issue). If I apply hacks to reduce optimization scope the code does go past hang. See attached hack. It seems kind of odd this would bite now after a lot of new use. Perhaps the new mix of functions and layout triggered it. Regards, Richard W. -- 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 request for omap fixes, v2 (Re: [PATCH 00/11] Omap fixes for 2.6.30-rc1)
* Tony Lindgren t...@atomide.com [090416 18:23]:
* Tony Lindgren t...@atomide.com [090414 14:48]:
Hi all,
Here are some omap fixes for review.
Also merged in Paul's clock fixes posted here earlier.
Russell, here's the pull request for you.
I merged in Paul's updated patch OMAP2/3 GPTIMER: allow system tick
GPTIMER to be changed in board-*.c files.
The diff to earlier series and the updated pull request are attached.
Cheers,
Tony
Index: linux-omap-2.6/arch/arm/mach-omap2/clock24xx.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/clock24xx.h 2009-04-20 10:42:21.0 -0700
+++ linux-omap-2.6/arch/arm/mach-omap2/clock24xx.h 2009-04-20 10:46:09.0 -0700
@@ -625,8 +625,8 @@ static struct clk func_32k_ck = {
.clkdm_name = wkup_clkdm,
};
-static struct clk secure_32k_fck = {
- .name = secure_32k_fck,
+static struct clk secure_32k_ck = {
+ .name = secure_32k_ck,
.ops = clkops_null,
.rate = 32768,
.flags = RATE_FIXED,
The following changes since commit 0882e8dd3aad33eca41696d463bb896e6c8817eb:
Linus Torvalds (1):
Linux 2.6.30-rc2
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-fixes
Arun KS (1):
OMAP1: clock: Typo fix for clock in omap1
Huang Weiyi (1):
ARM: OMAP3: remove duplicated #include
Jarkko Nikula (1):
ARM: OMAP2: Remove defines and resource init for OMAP24XX EAC
Kevin Hilman (2):
ARM: OMAP2/3: GPIO: do not attempt to wake-enable
OMAP: dmtimer: enable all timers to be wakeup events
Ladislav Michl (3):
ARM: OMAP: MMC: Remove unused power_pin
ARM: OMAP1: Simplify board-h2 MMC setup
ARM: OMAP1: Fix mmc_set_power GPIO usage
Paul Walmsley (4):
OMAP2xxx clock: init osc_ck, sys_ck internal lists early
OMAP2xxx clock: fix broken cpu_mask code
OMAP3 GPTIMER: fix GPTIMER12 IRQ
OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c
files
Roel Kluin (1):
ARM: OMAP2: possible division by 0
Roger Quadros (2):
ARM: OMAP3: Fixed spurious IRQ issue for GPIO interrupts
ARM: OMAP3: Clean up spurious interrupt check logic
Santosh Shilimkar (1):
ARM: OMAP: Fix for possible race condition in omap_free_dma()
Sergio Aguirre (1):
OMAP3: clock: Camera module doesn't have IDLEST bit
Tony Lindgren (2):
ARM: OMAP: Remove old dead gpio expander code
Merge branch 'omap-clock-fixes' into omap-fixes
arch/arm/mach-omap1/board-h2-mmc.c | 14 +---
arch/arm/mach-omap1/board-h3-mmc.c |6 +-
arch/arm/mach-omap1/board-h3.c | 101
arch/arm/mach-omap1/board-nokia770.c |6 +-
arch/arm/mach-omap1/mcbsp.c|4 +-
arch/arm/mach-omap2/board-h4.c | 95 --
arch/arm/mach-omap2/board-omap3beagle.c|4 +
arch/arm/mach-omap2/board-rx51.c |1 -
arch/arm/mach-omap2/clock24xx.c| 15 ++--
arch/arm/mach-omap2/clock24xx.h| 10 ++-
arch/arm/mach-omap2/clock34xx.h|7 +-
arch/arm/mach-omap2/devices.c | 33
arch/arm/mach-omap2/irq.c |4 +-
arch/arm/mach-omap2/timer-gp.c | 48 +++-
arch/arm/mach-omap2/usb-tusb6010.c |2 +-
arch/arm/plat-omap/dma.c | 13 ++--
arch/arm/plat-omap/dmtimer.c | 28 ---
arch/arm/plat-omap/gpio.c | 20 ++---
arch/arm/plat-omap/include/mach/dmtimer.h |2 +-
arch/arm/plat-omap/include/mach/eac.h | 100 ---
arch/arm/plat-omap/include/mach/gpioexpander.h | 35
arch/arm/plat-omap/include/mach/irda.h |4 -
arch/arm/plat-omap/include/mach/mmc.h |1 -
arch/arm/plat-omap/include/mach/timer-gp.h | 17
drivers/mmc/host/omap.c|2 -
25 files changed, 128 insertions(+), 444 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/mach/eac.h
delete mode 100644 arch/arm/plat-omap/include/mach/gpioexpander.h
create mode 100644 arch/arm/plat-omap/include/mach/timer-gp.h
