Suspend/Resume support with Omap2fb
Hi, I am using New Frame-Buffer driver which is based on DSS2 library submitted by Tomi, and I am trying to add full power management support. But things are not working out as expected, every time when I am issuing command "echo mem > /sys/power/state" the system doesn't go into off state. It always points to dss_prwdm, below are the steps I am following - - Build the kernel with CPU_IDLE - Enable all the PM flags # echo 1 > /sys/power/sleep_while_idle # echo 1 > /sys/power/clocks_off_while_idle # echo 1 > /sys/power/enable_off_mode - From Linux prompt issue command # echo mem > /sys/power/state The log is - r...@arago:~# echo mem > /sys/power/state <6>PM: Syncing filesystems ... PM: Syncing filesystems ... done. done. Freezing user space processes ... Freezing user space processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. done. Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done. Suspending console(s) (use no_console_suspend to debug) Suspending console(s) (use no_console_suspend to debug) <6>omap-backlight: suspending... omapfb_suspend omapfb_resume <6>omap-backlight: resuming... omap-backlight: suspending... omapfb_suspend Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (dss_pwrdm) didn't enter target state 0 Powerdomain (per_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend eth0: link down omapfb_resume omap-backlight: resuming... Restarting tasks ... Restarting tasks ... done. done. r...@arago:~# Some analysis which I observed during debugging this issue - - The root-cause is, DSS PowerDomain always shows it is in ON state (PWRDM_POWER_ON), and if I understand correctly this is only dependent on clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE enabled I am going to complete OFF state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing). - If I compile out framebuffer driver and include DSS2 and V4L2 driver, everything works fine. I am not sure how "omapfb" is being tied with PowerDomain. Again I have seen references in arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = "omapfb", not sure how this is being used. I believe if system is hitting OFF state, then my enable/disable paths are proper, but really not sure about why "mem" is causing problem here. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: HSMMC: Initialize hsmmc controller registers when resuming
On Tue, 10 Mar 2009 19:33:50 -0800 David Brownell wrote: > > It'd be nice to have a nice unambiguous set_voltage() > request from the MMC core. The set_ios() thing has > always been confusing. > set_ios() should be taken out back. But someone has to have the time to reimplement things. :/ -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. -- 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] OMAP: I2C: Use correct bit for CLOCKACTIVITY
On Wed, 2009-03-11 at 04:55 +0100, ext Woodruff, Richard wrote: > I think Nishant already said this but TRM is going to be updated to correct > McBSP. > > CBSPLP_SYSCONFIG_REG[9:8] CLOCKACTIVITY field description will be updated in > next TRM version: OMAP34XX v-R > > 0x0: McBSPi_ICLK clock can be switched-off > PRCM Functional clock can be switched-off > > 0x1: McBSPi_ICLK clock must be maintained during wake up period > PRCM Functional clock can be switched-off > > 0x2: McBSPi_ICLK clock can be switched-off > PRCM Functional clock must be maintained during wake up period > > 0x3: McBSPi_ICLK clock must be maintained during wake up period > PRCM Functional clock must be maintained during wakeup period > > Regards, > Richard W. I don't remember him saying exactly that. Wow, this looks like one really really good explanation for one of our PM effors with McBSP audio.. thank you! - Eero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: McBSP: Always maintain McBSP fclk while active
On Tue, 2009-03-10 at 15:29 +0100, Nikula Jarkko (Nokia-D/Helsinki) wrote: > Looks like a valid change eventhough haven't tested the actual problem. > Would it be possible with the PM branch and Beagle now? > > > Jarkko Now this appears to be inherently wrong =) Read this: http://marc.info/?l=linux-omap&m=123674373120880&w=2 (Of course I went in to mention "I am 100% certain the McBSP FCLK is the bit 8" =) - Eero -- 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: Hello Tomi Valkeinen, I have some questions about dss2 driver.
Hi Dae, I am attaching one patch which adds the support of rotation on top of Tomi's DSS library. But this patch is created against the patches posted by tomi long back. You can have look at _dispc_calc_and_set_row_inc and _dispc_set_rotation_mirroring function for reference to add the YUV support. I have tested it with YUV, UYVY, RGB16 and RGB24u pixel format. Currently it supports pixel and row increment calculation only for rotation case. Thanks and Regards, Hardik Shah > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of InKi Dae > Sent: Wednesday, March 11, 2009 10:28 AM > To: Tomi Valkeinen > Cc: linux-omap@vger.kernel.org > Subject: Hello Tomi Valkeinen, I have some questions about dss2 driver. > > I am using your dss2 driver downloaded from your git server and tried > to rotate an image(RGB24U and YUV2 format) using OMAPFB_ROT_DMA > command. > but I can't see rotated image on screen. I added variables for > rotating like below. as the result, LCD Panel is stoped. > > omapfb.rotate=2 > omapfb.vrfb=n > > > and then I tried again using OMAPFB_ROT_VRFB command like below. > > omapfb.rotate=2 > omapfb.vrfb=y > > In this case, I can see rotated image(only RGB24U format) on screen. > You asid "Rotation and mirroring currently only supports RGB565 and > RGB modes. VRFB does not support mirroring" through > /Documentation/arm/OMAP/DSS file. > > Doesn't your dss2 driver support DMA rotation? > I am trying to add rotation feature for YUV2 image using VRFB to your > dss2 driver. > > for this, I think that it have to change rot and mirror become 0 if > rotation_type is OMAPFB_ROT_VRFB to be rot=ofbi->rotation and mirror = > ofbi->mirror (in omapfb-main.c file) and > add codes for calculating offset0, offset1, pixel increment and row > increment value for YUV2 format also pixel size becomes 4 in YUV2 case > (in dispc.c fild). > omap_vrfb_setup function must be modifed also (in vrfb.c file)? > > Do you have any idea? > I need your help and advice. > > Thank you. > - InKi- > -- > 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 0002-Changes-Done-to-DSS-Library.patch Description: 0002-Changes-Done-to-DSS-Library.patch
Hello Tomi Valkeinen, I have some questions about dss2 driver.
I am using your dss2 driver downloaded from your git server and tried to rotate an image(RGB24U and YUV2 format) using OMAPFB_ROT_DMA command. but I can't see rotated image on screen. I added variables for rotating like below. as the result, LCD Panel is stoped. omapfb.rotate=2 omapfb.vrfb=n and then I tried again using OMAPFB_ROT_VRFB command like below. omapfb.rotate=2 omapfb.vrfb=y In this case, I can see rotated image(only RGB24U format) on screen. You asid "Rotation and mirroring currently only supports RGB565 and RGB modes. VRFB does not support mirroring" through /Documentation/arm/OMAP/DSS file. Doesn't your dss2 driver support DMA rotation? I am trying to add rotation feature for YUV2 image using VRFB to your dss2 driver. for this, I think that it have to change rot and mirror become 0 if rotation_type is OMAPFB_ROT_VRFB to be rot=ofbi->rotation and mirror = ofbi->mirror (in omapfb-main.c file) and add codes for calculating offset0, offset1, pixel increment and row increment value for YUV2 format also pixel size becomes 4 in YUV2 case (in dispc.c fild). omap_vrfb_setup function must be modifed also (in vrfb.c file)? Do you have any idea? I need your help and advice. Thank you. - InKi- -- 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] OMAP: I2C: Use correct bit for CLOCKACTIVITY
> > How about McBSP? Same TRM.. I2C, Table 18-5 tells exactly the opposite > > for I2C than what's said in Table 18-44: I2C_SYSC!! > > > > Please, Richard? > > > > - Eero > > To answer to myself, I am 100% certain the McBSP FCLK is the > bit 8. I should have sent a patch about that already.. > > Kind of worried as could they really change that much? > >From page to page and block to block and within a block...=) I think Nishant already said this but TRM is going to be updated to correct McBSP. CBSPLP_SYSCONFIG_REG[9:8] CLOCKACTIVITY field description will be updated in next TRM version: OMAP34XX v-R 0x0: McBSPi_ICLK clock can be switched-off PRCM Functional clock can be switched-off 0x1: McBSPi_ICLK clock must be maintained during wake up period PRCM Functional clock can be switched-off 0x2: McBSPi_ICLK clock can be switched-off PRCM Functional clock must be maintained during wake up period 0x3: McBSPi_ICLK clock must be maintained during wake up period PRCM Functional clock must be maintained during wakeup period 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: [PATCH] OMAP: HSMMC: Initialize hsmmc controller registers when resuming
On Monday 23 February 2009, Adrian Hunter wrote: > Although I have not tested it, I very much doubt > dual-voltage cards work. That is because VMMC1_185V > is zero, which has the side-effect of turning the > regulator off (see arch/arm/mach-omap2/mmc-twl4030.c) And a second reason to know they don't quite work ... in the file drivers/mmc/host/omap_hsmmc.c, omap_mmc_set_ios() sets the voltage for MMC_POWER_OFF (0) or MMC_POWER_UP (1_, which gives the initial setting -- e.g. 3.15 Volts, so it can enumerate at the high range. But after enumerating the card at that voltage, checking the OCR values, and concluding that the slot and card can both run at 1.85V ... the MMC_POWER_ON (2) code is used. But the driver completely ignores it ... the low voltage (more power-efficient!) voltage range never kicks in. It'd be nice to have a nice unambiguous set_voltage() request from the MMC core. The set_ios() thing has always been confusing. - Dave -- 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: What did omap2_disp_get_dss morph into?
Hi David, You must be having "struct omap_display" pointer populated in your driver during probe, you just need to stick with display->enable and Display->disable function call. These functions in turn enables and disables clocks and save/restores the context. If you provide some more details about your use case, then I would be able to understand better. One more thing I just wanted to share, there some bugs we found during our release cycle in save and restore context path which I will be publishing soon. So please let me know if you are facing some issues, I can assist you with this. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of david.hag...@gmail.com > Sent: Wednesday, March 11, 2009 2:02 AM > To: linux-omap@vger.kernel.org > Subject: What did omap2_disp_get_dss morph into? > > I am trying to get the TI accelerated video driver to build against > the > current DSS2 kernel image, and I think I am this close || to getting > it to > go, but I am missing a pair of functions: omap2_disp_get_dss and > omap2_disp_put_dss. > > Obviously, they've changed into something else - what did they morph > into? > > > -- > 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: Problems while designing TPS65023 regulator driver
On Mon, Mar 09, 2009 at 04:45:26PM -0800, David Brownell wrote: > On Sunday 08 March 2009, Mark Brown wrote: > > > - Regulators not marked as "boot_on" or "always_on" won't > > >be active (and usecount will be 0) on return from setup. > > This breaks the idea that we don't do anything unless explictly told to > > do so. > I'm not sure where you're drawing this "explicitly" line, but > clearly it's not where I would draw it! The board init code > explicitly said "here's a regulator, with these settings for > the boot_on and always_on flags". If neither was set, they > are obviously clear ... so the regulator shouldn't be enabled. At the minute a zero initialised set of constraints means "don't touch anything" - it doesn't grant any permissions to do anything, all that can actually be done is inspect the state. Some of the drivers use this currently, having a block of regulator constraint data in a larger block of platform data and registering all regulators on the chip unconditionally. Requiring boot_on or always_on to be set would mean that these drivers would start powering everything off once the change is merged unless the drivers are changed first. If we are going to make this change it might be best to first spend a release printing a big fat warning so it's harder for people to get surprised by it, especially with stuff getting merged via platform trees. > > I did actually still consider adding code to power off the > > regulator but thought that there may also be situations where the state > > really is unknown (eg, it depends on what the system booted from) and > > it'd be useful to be able to punt to the consumers to figure it out. The other use case I should've mentioned is for people who are reverse engineering systems and initially want to fire things up and inspect the state they get left with before they go figuring out what (if anything) they want to do with it. Even if you do know the design this can be quite handy for testing that everything came up as expected, the kernel provides a fairly convenient UI. > The core problem with that thought is that if you try doing that, > then consumers have exactly zero ways to fix the issue. It's the > scenario I listed above: regulator is enabled, but refcount is > zero. So they're not allowed to disable. It can do it by enabling (which is a noop) and then disabling - it's not nice and wasn't really intentional but it gets the job done. > That's in addition to the fact that "unknown" states are > extremely error prone. The state after initialization should > fully known, without having to play such guessing games. Yes, doing it via constriants is clearly better - I'm more thinking about this in terms of "if you really want to do it this is how" than as something I'd recommend people use. > defined values. Adding a second "always_on" flag makes for > some confusion, since it only defines a third state, not a > pair of states (it's not orthogonal). We should just be able to remove always_on; it's equivalent to setting boot_on and not enabling REGULATOR_CHANGE_STATUS. I'll look into that but it's got cross tree issues too. > always have the consumer ops delegate to the real regulator. > And have that real regulator's usecount set to one when it's > enabled at boot time, so regulator_disable() will work then. Clearly. I'm wondering how that plays with multiple consumers, though. Consumers will be able to disable regulators that were left on but they'll need something to let them figure out why the device was left on. Or just not worry about supporting such users too strongly suggest that they should be using something that gets added to the constraints. Fancy kicking off a couple of new discussions on lkml? -- 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 12/12] ARM: OMAP3: MUSB initialization for omap hw
From: Felipe Balbi Create a generic board-file for initializing usb on omap2430 and omap3 boards. Patch modified by Tony to build the module based on CONFIG_USB_MUSB_SOC. Also merged in a patch adding the nop xceiv from Ajay Kumar Gupta . Signed-off-by: Ajay Kumar Gupta Signed-off-by: Felipe Balbi Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/Makefile |2 arch/arm/mach-omap2/board-2430sdp.c |2 arch/arm/mach-omap2/board-ldp.c |2 arch/arm/mach-omap2/board-omap3beagle.c |2 arch/arm/mach-omap2/board-omap3pandora.c |2 arch/arm/mach-omap2/board-overo.c|2 arch/arm/mach-omap2/usb-musb.c | 185 ++ arch/arm/plat-omap/include/mach/usb.h|8 + 8 files changed, 205 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/usb-musb.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index bbd12bc..53403a0 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -39,3 +39,5 @@ obj-$(CONFIG_MACH_OVERO) += board-overo.o \ obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ mmc-twl4030.o +# Platform specific device init code +obj-$(CONFIG_USB_MUSB_SOC) += usb-musb.o diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 83fa372..9619e25 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -35,6 +35,7 @@ #include #include #include +#include #include "mmc-twl4030.h" @@ -251,6 +252,7 @@ static void __init omap_2430sdp_init(void) omap_board_config_size = ARRAY_SIZE(sdp2430_config); omap_serial_init(); twl4030_mmc_init(mmc); + usb_musb_init(); } static void __init omap_2430sdp_map_io(void) diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c index f6a1345..b7dbc6c 100644 --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@ -38,6 +38,7 @@ #include #include #include +#include #include "mmc-twl4030.h" @@ -162,6 +163,7 @@ static void __init omap_ldp_init(void) omap_board_config_size = ARRAY_SIZE(ldp_config); omap_serial_init(); twl4030_mmc_init(mmc); + usb_musb_init(); } static void __init omap_ldp_map_io(void) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index e3c8628..2f3d821 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -41,6 +41,7 @@ #include #include #include +#include #include "mmc-twl4030.h" @@ -313,6 +314,7 @@ static void __init omap3_beagle_init(void) /* REVISIT leave DVI powered down until it's needed ... */ gpio_direction_output(170, true); + usb_musb_init(); omap3beagle_flash_init(); } diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c index 6e17180..16e2128 100644 --- a/arch/arm/mach-omap2/board-omap3pandora.c +++ b/arch/arm/mach-omap2/board-omap3pandora.c @@ -34,6 +34,7 @@ #include #include #include +#include #include "mmc-twl4030.h" @@ -200,6 +201,7 @@ static void __init omap3pandora_init(void) spi_register_board_info(omap3pandora_spi_board_info, ARRAY_SIZE(omap3pandora_spi_board_info)); omap3pandora_ads7846_init(); + usb_musb_init(); } static void __init omap3pandora_map_io(void) diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c index 61f8e23..d785aa8 100644 --- a/arch/arm/mach-omap2/board-overo.c +++ b/arch/arm/mach-omap2/board-overo.c @@ -44,6 +44,7 @@ #include #include #include +#include #include "mmc-twl4030.h" @@ -223,6 +224,7 @@ static void __init overo_init(void) omap_serial_init(); twl4030_mmc_init(mmc); overo_flash_init(); + usb_musb_init(); if ((gpio_request(OVERO_GPIO_W2W_NRESET, "OVERO_GPIO_W2W_NRESET") == 0) && diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c new file mode 100644 index 000..927c2d9 --- /dev/null +++ b/arch/arm/mach-omap2/usb-musb.c @@ -0,0 +1,185 @@ +/* + * linux/arch/arm/mach-omap2/usb-musb.c + * + * This file will contain the board specific details for the + * MENTOR USB OTG controller on OMAP3430 + * + * Copyright (C) 2007-2008 Texas Instruments + * Copyright (C) 2008 Nokia Corporation + * Author: Vikram Pandita + * + * Generalization by: + * Felipe Balbi + * + * 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 +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include
[PATCH 11/12] ARM: OMAP3: Add base address definitions and resources for OMAP 3 IS
This replaces earlier patch from Sergio Aguirre titled "[REVIEW PATCH 03/14]
OMAP34XX: CAM: Resources fixes".
Signed-off-by: Sakari Ailus
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/devices.c | 108
arch/arm/plat-omap/include/mach/omap34xx.h | 27 +++
2 files changed, 135 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index ce03fa7..bf84305 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -28,6 +28,113 @@
#include
#include
+#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
+
+static struct resource cam_resources[] = {
+ {
+ .start = OMAP24XX_CAMERA_BASE,
+ .end= OMAP24XX_CAMERA_BASE + 0xfff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_24XX_CAM_IRQ,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct platform_device omap_cam_device = {
+ .name = "omap24xxcam",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(cam_resources),
+ .resource = cam_resources,
+};
+
+static inline void omap_init_camera(void)
+{
+ platform_device_register(&omap_cam_device);
+}
+
+#elif defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE)
+
+static struct resource omap3isp_resources[] = {
+ {
+ .start = OMAP3430_ISP_BASE,
+ .end= OMAP3430_ISP_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_CBUFF_BASE,
+ .end= OMAP3430_ISP_CBUFF_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_CCP2_BASE,
+ .end= OMAP3430_ISP_CCP2_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_CCDC_BASE,
+ .end= OMAP3430_ISP_CCDC_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_HIST_BASE,
+ .end= OMAP3430_ISP_HIST_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_H3A_BASE,
+ .end= OMAP3430_ISP_H3A_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_PREV_BASE,
+ .end= OMAP3430_ISP_PREV_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_RESZ_BASE,
+ .end= OMAP3430_ISP_RESZ_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_SBL_BASE,
+ .end= OMAP3430_ISP_SBL_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_CSI2A_BASE,
+ .end= OMAP3430_ISP_CSI2A_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3430_ISP_CSI2PHY_BASE,
+ .end= OMAP3430_ISP_CSI2PHY_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_34XX_CAM_IRQ,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct platform_device omap3isp_device = {
+ .name = "omap3isp",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap3isp_resources),
+ .resource = omap3isp_resources,
+};
+
+static inline void omap_init_camera(void)
+{
+ platform_device_register(&omap3isp_device);
+}
+#else
+static inline void omap_init_camera(void)
+{
+}
+#endif
+
#if defined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
#define OMAP2_MBOX_BASEIO_ADDRESS(OMAP24XX_MAILBOX_BASE)
@@ -506,6 +613,7 @@ static int __init omap2_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
omap_hsmmc_reset();
+ omap_init_camera();
omap_init_mbox();
omap_init_mcspi();
omap_hdq_init();
diff --git a/arch/arm/plat-omap/include/mach/omap34xx.h
b/arch/arm/plat-omap/include/mach/omap34xx.h
index 8e0479f..e50c98f 100644
--- a/arch/arm/plat-omap/include/mach/omap34xx.h
+++ b/arch/arm/plat-omap/include/mach/omap34xx.h
@@ -49,6 +49,33 @@
#define OMAP343X_CTRL_BASE OMAP343X_SCM_BASE
#define OMAP34XX_IC_BASE 0x4820
+
+#define OMAP3430_ISP_BASE (L4_34XX_BASE + 0xBC000)
+#define OMAP3430_ISP_CBUFF_BASE(OMAP3430_ISP_BASE + 0x0100)
+#define OMAP3430_ISP_CCP2_BASE (OMAP3430_ISP_B
[PATCH 10/12] ARM: OMAP3: mmc-twl4030 allow arbitrary slot names
From: Adrian Hunter
Signed-off-by: Adrian Hunter
Acked-by: David Brownell
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mmc-twl4030.c |5 -
arch/arm/mach-omap2/mmc-twl4030.h |1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 9f53d22..9831b2b 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -402,7 +402,10 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
return;
}
- sprintf(twl->name, "mmc%islot%i", c->mmc, 1);
+ if (c->name)
+ strncpy(twl->name, c->name, HSMMC_NAME_LEN);
+ else
+ sprintf(twl->name, "mmc%islot%i", c->mmc, 1);
mmc->slots[0].name = twl->name;
mmc->nr_slots = 1;
mmc->slots[0].wires = c->wires;
diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
b/arch/arm/mach-omap2/mmc-twl4030.h
index 0aa1686..ea59e86 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -14,6 +14,7 @@ struct twl4030_hsmmc_info {
boolcover_only; /* No card detect - just cover switch */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
+ char*name; /* or NULL for default */
struct device *dev; /* returned: pointer to mmc adapter */
};
--
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: [APPLIED] [PATCH v2] OMAP: Store reboot mode in scratchpad on OMAP34xx
* David Brownell [090310 14:05]: > On Tuesday 10 March 2009, Tony Lindgren wrote: > > This patch has been applied to the linux-omap > > by youw fwiendly patch wobot. > > CC arch/arm/mach-omap2/prcm.o > arch/arm/mach-omap2/prcm.c: In function 'omap_prcm_arch_reset': > arch/arm/mach-omap2/prcm.c:56: error: 'OMAP343X_SCRATCHPAD' undeclared (first > use in this function) > arch/arm/mach-omap2/prcm.c:56: error: (Each undeclared identifier is reported > only once > arch/arm/mach-omap2/prcm.c:56: error: for each function it appears in.) > make[1]: *** [arch/arm/mach-omap2/prcm.o] Error 1 > make: *** [arch/arm/mach-omap2] Error 2 I already pushed a fix for that as commit 3388c8ffb612af2c9d4267e0401378c3afb05f5f. Tony > > > > Commit: 73b65cde9647508313b3d686dff0f3d1d92482d1 > > > > PatchWorks > > http://patchwork.kernel.org/patch/10718/ > > > > Git > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=73b65cde9647508313b3d686dff0f3d1d92482d1 > > > > > > > -- 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 09/12] ARM: OMAP3: mmc-twl4030 add cover switch
From: Adrian Hunter
Allow a cover switch to be used to cause a rescan of the
MMC slot.
Signed-off-by: Adrian Hunter
Acked-by: David Brownell
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mmc-twl4030.c | 13 -
arch/arm/mach-omap2/mmc-twl4030.h |1 +
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 2becaf3..9f53d22 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -100,6 +100,14 @@ static int twl_mmc_get_ro(struct device *dev, int slot)
return gpio_get_value_cansleep(mmc->slots[0].gpio_wp);
}
+static int twl_mmc_get_cover_state(struct device *dev, int slot)
+{
+ struct omap_mmc_platform_data *mmc = dev->platform_data;
+
+ /* NOTE: assumes card detect signal is active-low */
+ return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
+}
+
/*
* MMC Slot Initialization.
*/
@@ -410,7 +418,10 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
mmc->slots[0].switch_pin = c->gpio_cd;
mmc->slots[0].card_detect_irq = gpio_to_irq(c->gpio_cd);
- mmc->slots[0].card_detect = twl_mmc_card_detect;
+ if (c->cover_only)
+ mmc->slots[0].get_cover_state =
twl_mmc_get_cover_state;
+ else
+ mmc->slots[0].card_detect = twl_mmc_card_detect;
} else
mmc->slots[0].switch_pin = -EINVAL;
diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
b/arch/arm/mach-omap2/mmc-twl4030.h
index 21d3572..0aa1686 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -11,6 +11,7 @@ struct twl4030_hsmmc_info {
u8 wires; /* 1/4/8 wires */
booltransceiver;/* MMC-2 option */
boolext_clock; /* use external pin for input clock */
+ boolcover_only; /* No card detect - just cover switch */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
struct device *dev; /* returned: pointer to mmc adapter */
--
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: [APPLIED] [PATCH v2] OMAP: Store reboot mode in scratchpad on OMAP34xx
On Tuesday 10 March 2009, Tony Lindgren wrote: > This patch has been applied to the linux-omap > by youw fwiendly patch wobot. CC arch/arm/mach-omap2/prcm.o arch/arm/mach-omap2/prcm.c: In function 'omap_prcm_arch_reset': arch/arm/mach-omap2/prcm.c:56: error: 'OMAP343X_SCRATCHPAD' undeclared (first use in this function) arch/arm/mach-omap2/prcm.c:56: error: (Each undeclared identifier is reported only once arch/arm/mach-omap2/prcm.c:56: error: for each function it appears in.) make[1]: *** [arch/arm/mach-omap2/prcm.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 > > Commit: 73b65cde9647508313b3d686dff0f3d1d92482d1 > > PatchWorks > http://patchwork.kernel.org/patch/10718/ > > Git > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=73b65cde9647508313b3d686dff0f3d1d92482d1 > > > -- 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 08/12] ARM: OMAP3: mmc-twl4030 fix for vmmc = 0
From: David Brownell
Resolve longstanding issue noted by Adrian Hunter: confusion
between settting VSEL=0 (which is 1.8V on MMC1) and poweroff.
Also, leave VSEL alone if we're just powering the regulator off.
Signed-off-by: David Brownell
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mmc-twl4030.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 042035c..2becaf3 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -178,7 +178,10 @@ static int twl_mmc_resume(struct device *dev, int slot)
static int twl_mmc_set_voltage(struct twl_mmc_controller *c, int vdd)
{
int ret;
- u8 vmmc, dev_grp_val;
+ u8 vmmc = 0, dev_grp_val;
+
+ if (!vdd)
+ goto doit;
if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP) {
/* VMMC1: max 220 mA. And for 8-bit mode,
@@ -203,8 +206,7 @@ static int twl_mmc_set_voltage(struct twl_mmc_controller
*c, int vdd)
/* error if VSIM needed */
break;
default:
- vmmc = 0;
- break;
+ return -EINVAL;
}
} else if (c->twl_vmmc_dev_grp == VMMC2_DEV_GRP) {
/* VMMC2: max 100 mA */
@@ -230,21 +232,21 @@ static int twl_mmc_set_voltage(struct twl_mmc_controller
*c, int vdd)
vmmc = VMMC2_315V;
break;
default:
- vmmc = 0;
- break;
+ return -EINVAL;
}
} else {
- return 0;
+ return -EINVAL;
}
- if (vmmc)
+doit:
+ if (vdd)
dev_grp_val = VMMC_DEV_GRP_P1; /* Power up */
else
dev_grp_val = LDO_CLR; /* Power down */
ret = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
dev_grp_val, c->twl_vmmc_dev_grp);
- if (ret)
+ if (ret || !vdd)
return ret;
ret = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
--
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 07/12] ARM: OMAP3: mmc-twl4030 add MMC3 support
From: Grazvydas Ignotas
Device connected to MMC3 is assumed to be self-powered, so
set_power() function is empty. It can't be omited because
host driver requires it. Array size for hsmmc[] is specified
because hsmmc[2].name is needed for MMC3 name.
Also fix a leak which happens if invalid controller id
is passed.
Signed-off-by: Grazvydas Ignotas
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-omap3pandora.c |6 ++
arch/arm/mach-omap2/mmc-twl4030.c| 19 +--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 7a46a65..6e17180 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -55,6 +55,12 @@ static struct twl4030_hsmmc_info omap3pandora_mmc[] = {
.ext_clock = 1,
.transceiver= true,
},
+ {
+ .mmc= 3,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
{} /* Terminator */
};
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 6399874..042035c 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -62,7 +62,7 @@ static struct twl_mmc_controller {
u8 twl_vmmc_dev_grp;
u8 twl_mmc_dedicated;
charname[HSMMC_NAME_LEN + 1];
-} hsmmc[] = {
+} hsmmc[OMAP34XX_NR_MMC] = {
{
.twl_vmmc_dev_grp = VMMC1_DEV_GRP,
.twl_mmc_dedicated = VMMC1_DEDICATED,
@@ -347,6 +347,16 @@ static int twl_mmc2_set_power(struct device *dev, int
slot, int power_on, int vd
return ret;
}
+static int twl_mmc3_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ /*
+* Assume MMC3 has self-powered device connected, for example on-board
+* chip with external power source.
+*/
+ return 0;
+}
+
static struct omap_mmc_platform_data *hsmmc_data[OMAP34XX_NR_MMC] __initdata;
void __init twl4030_mmc_init(struct twl4030_hsmmc_info *controllers)
@@ -414,7 +424,7 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
/* NOTE: we assume OMAP's MMC1 and MMC2 use
* the TWL4030's VMMC1 and VMMC2, respectively;
-* and that OMAP's MMC3 isn't used.
+* and that MMC3 device has it's own power source.
*/
switch (c->mmc) {
@@ -429,8 +439,13 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
else
mmc->slots[0].ocr_mask = MMC_VDD_165_195;
break;
+ case 3:
+ mmc->slots[0].set_power = twl_mmc3_set_power;
+ mmc->slots[0].ocr_mask = MMC_VDD_165_195;
+ break;
default:
pr_err("MMC%d configuration not supported!\n", c->mmc);
+ kfree(mmc);
continue;
}
hsmmc_data[c->mmc - 1] = mmc;
--
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 05/12] ARM: OMAP3: mmc-twl4030 voltage cleanup
From: David Brownell
Correct twl4030 MMC power switching: fix voltage ranges reported
for each slot, and handle them fully.
Lies corrected:
- MMC-1 doesn't support the 2.6-2.7 Volt range
- MMC-2 can't normally support anything except 1.8V
Omissions corrected
- MMC-1 *does* handle the 2.8-2.9 Volt range
- MMC-2 can handle 2.5-3.2 Volt cards, given a transceiver
Add transciever support for MMC-2; enable it for Overo and Pandora.
(Depends on something else to have set up pinmuxing for control
signals instead of as MMC2_DAT4..7 pins.)
Also shrink twl4030_hsmmc_info a smidgeon ... padding is all gone.
Signed-off-by: David Brownell
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-omap3pandora.c |1
arch/arm/mach-omap2/board-overo.c|1
arch/arm/mach-omap2/mmc-twl4030.c| 127 +++---
arch/arm/mach-omap2/mmc-twl4030.h|3 -
4 files changed, 84 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index b319610..7a46a65 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -53,6 +53,7 @@ static struct twl4030_hsmmc_info omap3pandora_mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= 127,
.ext_clock = 1,
+ .transceiver= true,
},
{} /* Terminator */
};
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 82b3dc5..61f8e23 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -209,6 +209,7 @@ static struct twl4030_hsmmc_info mmc[] __initdata = {
.wires = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .transceiver= true,
},
{} /* Terminator */
};
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 909f57c..42ac13f 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -44,6 +44,7 @@
#define VMMC2_315V 0x0c
#define VMMC2_300V 0x0b
#define VMMC2_285V 0x0a
+#define VMMC2_280V 0x09
#define VMMC2_260V 0x08
#define VMMC2_185V 0x06
#define VMMC2_DEDICATED0x2E
@@ -166,56 +167,73 @@ static int twl_mmc_resume(struct device *dev, int slot)
/*
* Sets the MMC voltage in twl4030
*/
+
+#define MMC1_OCR (MMC_VDD_165_195 \
+ |MMC_VDD_28_29|MMC_VDD_29_30|MMC_VDD_30_31|MMC_VDD_31_32)
+#define MMC2_OCR (MMC_VDD_165_195 \
+ |MMC_VDD_25_26|MMC_VDD_26_27|MMC_VDD_27_28 \
+ |MMC_VDD_28_29|MMC_VDD_29_30|MMC_VDD_30_31|MMC_VDD_31_32)
+
static int twl_mmc_set_voltage(struct twl_mmc_controller *c, int vdd)
{
int ret;
u8 vmmc, dev_grp_val;
- switch (1 << vdd) {
- case MMC_VDD_35_36:
- case MMC_VDD_34_35:
- case MMC_VDD_33_34:
- case MMC_VDD_32_33:
- case MMC_VDD_31_32:
- case MMC_VDD_30_31:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
- vmmc = VMMC1_315V;
- else
- vmmc = VMMC2_315V;
- break;
- case MMC_VDD_29_30:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
- vmmc = VMMC1_315V;
- else
- vmmc = VMMC2_300V;
- break;
- case MMC_VDD_27_28:
- case MMC_VDD_26_27:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
- vmmc = VMMC1_285V;
- else
- vmmc = VMMC2_285V;
- break;
- case MMC_VDD_25_26:
- case MMC_VDD_24_25:
- case MMC_VDD_23_24:
- case MMC_VDD_22_23:
- case MMC_VDD_21_22:
- case MMC_VDD_20_21:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
- vmmc = VMMC1_285V;
- else
- vmmc = VMMC2_260V;
- break;
- case MMC_VDD_165_195:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
+ if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP) {
+ /* VMMC1: max 220 mA. And for 8-bit mode,
+* VSIM: max 50 mA
+*/
+ switch (1 << vdd) {
+ case MMC_VDD_165_195:
vmmc = VMMC1_185V;
- else
+ /* and VSIM_180V */
+ break;
+ case MMC_VDD_28_29:
+ vmmc = VMMC1_285V;
+ /* and VSIM_280V */
+ break;
+ case MMC_VDD_29_30:
+ case MMC_VDD_30_31:
+ vmmc = VMMC1_300V;
+ /* and VSIM_300V */
+ break;
+
[PATCH 06/12] ARM: OMAP3: mmc-twl4030 init passes device nodes back
From: David Brownell
When setting up HSMMC devices, pass pass the device nodes back so
board code can linking them to their power supply regulators.
Signed-off-by: David Brownell
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mmc-twl4030.c | 10 ++
arch/arm/mach-omap2/mmc-twl4030.h |1 +
arch/arm/plat-omap/devices.c |3 +++
arch/arm/plat-omap/include/mach/mmc.h |2 ++
4 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 42ac13f..6399874 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -436,6 +437,15 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
}
omap2_init_mmc(hsmmc_data, OMAP34XX_NR_MMC);
+
+ /* pass the device nodes back to board setup code */
+ for (c = controllers; c->mmc; c++) {
+ struct omap_mmc_platform_data *mmc = hsmmc_data[c->mmc - 1];
+
+ if (!c->mmc || c->mmc > nr_hsmmc)
+ continue;
+ c->dev = mmc->dev;
+ }
}
#endif
diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
b/arch/arm/mach-omap2/mmc-twl4030.h
index 380dde7..21d3572 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -13,6 +13,7 @@ struct twl4030_hsmmc_info {
boolext_clock; /* use external pin for input clock */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
+ struct device *dev; /* returned: pointer to mmc adapter */
};
#ifdefined(CONFIG_TWL4030_CORE) && \
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 208dbb1..87fb7ff 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -228,6 +228,9 @@ int __init omap_mmc_add(const char *name, int id, unsigned
long base,
ret = platform_device_add(pdev);
if (ret)
goto fail;
+
+ /* return device handle to board setup code */
+ data->dev = &pdev->dev;
return 0;
fail:
diff --git a/arch/arm/plat-omap/include/mach/mmc.h
b/arch/arm/plat-omap/include/mach/mmc.h
index 73a9e15..4435bd4 100644
--- a/arch/arm/plat-omap/include/mach/mmc.h
+++ b/arch/arm/plat-omap/include/mach/mmc.h
@@ -37,6 +37,8 @@
#define OMAP_MMC_MAX_SLOTS 2
struct omap_mmc_platform_data {
+ /* back-link to device */
+ struct device *dev;
/* number of slots per controller */
unsigned nr_slots:2;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/12] ARM: OMAP3: mmc-twl4030 fix name buffer length
From: Adrian Hunter
Add 1 to buffer length for null terminator.
Signed-off-by: Adrian Hunter
Acked-by: David Brownell
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mmc-twl4030.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 437f520..909f57c 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -59,7 +59,7 @@ static struct twl_mmc_controller {
struct omap_mmc_platform_data *mmc;
u8 twl_vmmc_dev_grp;
u8 twl_mmc_dedicated;
- charname[HSMMC_NAME_LEN];
+ charname[HSMMC_NAME_LEN + 1];
} hsmmc[] = {
{
.twl_vmmc_dev_grp = VMMC1_DEV_GRP,
--
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 03/12] ARM: OMAP3: Add more GPIO mux options
This patch adds several new GPIO pins and updates
the pin naming comments.
The patch is based on earlier patches on linux-omap
list by Manikandan Pillai ,
Vaibhav Hiremath and
David Brownell .
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mux.c | 27 +++
arch/arm/plat-omap/include/mach/mux.h | 13 +
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index dacb41f..026c4fc 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -453,10 +453,37 @@ MUX_CFG_34XX("AC1_3430_USB3FS_PHY_MM3_TXEN_N", 0x18a,
/* 34XX GPIO - bidirectional, unless the name has an "_OUT" suffix.
+ * (Always specify PIN_INPUT, except for names suffixed by "_OUT".)
* No internal pullup/pulldown without "_UP" or "_DOWN" suffix.
*/
+MUX_CFG_34XX("AF26_34XX_GPIO0", 0x1e0,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("AF22_34XX_GPIO9", 0xa18,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
MUX_CFG_34XX("AH8_34XX_GPIO29", 0x5fa,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("U8_34XX_GPIO54_OUT", 0x0b4,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX("U8_34XX_GPIO54_DOWN", 0x0b4,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX("L8_34XX_GPIO63", 0x0ce,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("G25_34XX_GPIO86_OUT", 0x0fc,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX("AG4_34XX_GPIO134_OUT", 0x160,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX("AE4_34XX_GPIO136_OUT", 0x164,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX("AF6_34XX_GPIO140_UP", 0x16c,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AE6_34XX_GPIO141", 0x16e,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("AF5_34XX_GPIO142", 0x170,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("AE5_34XX_GPIO143", 0x172,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("H19_34XX_GPIO164_OUT", 0x19c,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
};
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index f4362b8..f7e298a 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -788,7 +788,20 @@ enum omap34xx_index {
* - "_DOWN" suffix (GPIO3_DOWN) with internal pulldown
* - "_OUT" suffix (GPIO3_OUT) for output-only pins (unlike 24xx)
*/
+ AF26_34XX_GPIO0,
+ AF22_34XX_GPIO9,
AH8_34XX_GPIO29,
+ U8_34XX_GPIO54_OUT,
+ U8_34XX_GPIO54_DOWN,
+ L8_34XX_GPIO63,
+ G25_34XX_GPIO86_OUT,
+ AG4_34XX_GPIO134_OUT,
+ AE4_34XX_GPIO136_OUT,
+ AF6_34XX_GPIO140_UP,
+ AE6_34XX_GPIO141,
+ AF5_34XX_GPIO142,
+ AE5_34XX_GPIO143,
+ H19_34XX_GPIO164_OUT,
J25_34XX_GPIO170,
};
--
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 02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx
From: Juha Yrjola
The reboot mode can be communicated to a bootloader (or the
kernel itself) with a scratchpad register. This functionality
is especially useful, if userspace is allowed to change
the reboot mode.
Patch updated by Tony to also define the BOODMOD registers.
Signed-off-by: Juha Yrjola
Acked-by: Kevin Hilman
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/prcm.c| 14 --
arch/arm/plat-omap/include/mach/control.h |9 +
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index f945156..12c0e03 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#include "clock.h"
@@ -43,9 +44,18 @@ void omap_prcm_arch_reset(char mode)
if (cpu_is_omap24xx())
prcm_offs = WKUP_MOD;
- else if (cpu_is_omap34xx())
+ else if (cpu_is_omap34xx()) {
+ u32 l;
+
prcm_offs = OMAP3430_GR_MOD;
- else
+ l = ('B' << 24) | ('M' << 16) | mode;
+ /* Reserve the first word in scratchpad for communicating
+* with the boot ROM. A pointer to a data structure
+* describing the boot process can be stored there,
+* cf. OMAP34xx TRM, Initialization / Software Booting
+* Configuration. */
+ omap_writel(l, OMAP343X_SCRATCHPAD + 4);
+ } else
WARN_ON(1);
prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
diff --git a/arch/arm/plat-omap/include/mach/control.h
b/arch/arm/plat-omap/include/mach/control.h
index 269147f..1e1bcff 100644
--- a/arch/arm/plat-omap/include/mach/control.h
+++ b/arch/arm/plat-omap/include/mach/control.h
@@ -189,6 +189,15 @@
#define OMAP2_PBIASLITEPWRDNZ0 (1 << 1)
#define OMAP2_PBIASLITEVMODE0 (1 << 0)
+/* CONTROL_IVA2_BOOTMOD bits */
+#define OMAP3_IVA2_BOOTMOD_SHIFT 0
+#define OMAP3_IVA2_BOOTMOD_MASK(0xf << 0)
+#define OMAP3_IVA2_BOOTMOD_IDLE(0x1 << 0)
+
+#define OMAP343X_SCRATCHPAD_ROM(OMAP343X_CTRL_BASE + 0x860)
+#define OMAP343X_SCRATCHPAD(OMAP343X_CTRL_BASE + 0x910)
+#define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C
+
#ifndef __ASSEMBLY__
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
extern void __iomem *omap_ctrl_base_get(void);
--
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 01/12] ARM: OMAP3: Remove unused CONFIG_I2C2_OMAP_BEAGLE
From: Jarkko Nikula
There is no CONFIG_I2C2_OMAP_BEAGLE in mainline and it is under
removal in linux-omap also so remove this dead code now.
Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-omap3beagle.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index e39cd2c..e3c8628 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -175,9 +175,6 @@ static int __init omap3_beagle_i2c_init(void)
{
omap_register_i2c_bus(1, 2600, beagle_i2c_boardinfo,
ARRAY_SIZE(beagle_i2c_boardinfo));
-#ifdef CONFIG_I2C2_OMAP_BEAGLE
- omap_register_i2c_bus(2, 400, NULL, 0);
-#endif
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, NULL, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/12] Omap3 updates for the merge window after 2.6.29
Hi all, Here are the patches I promised last week, sorry for the delay in posting them. I ended up leaving out the mach-omap3/board-*.c files as they still need a bit of work. I may post one more series after this to add few more omap3 boards if we have enough time. Cheers, Tony --- Adrian Hunter (3): ARM: OMAP3: mmc-twl4030 allow arbitrary slot names ARM: OMAP3: mmc-twl4030 add cover switch ARM: OMAP3: mmc-twl4030 fix name buffer length David Brownell (3): ARM: OMAP3: mmc-twl4030 fix for vmmc = 0 ARM: OMAP3: mmc-twl4030 init passes device nodes back ARM: OMAP3: mmc-twl4030 voltage cleanup Felipe Balbi (1): ARM: OMAP3: MUSB initialization for omap hw Grazvydas Ignotas (1): ARM: OMAP3: mmc-twl4030 add MMC3 support Jarkko Nikula (1): ARM: OMAP3: Remove unused CONFIG_I2C2_OMAP_BEAGLE Juha Yrjola (1): ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx Tony Lindgren (2): ARM: OMAP3: Add base address definitions and resources for OMAP 3 IS ARM: OMAP3: Add more GPIO mux options arch/arm/mach-omap2/Makefile |2 arch/arm/mach-omap2/board-2430sdp.c|2 arch/arm/mach-omap2/board-ldp.c|2 arch/arm/mach-omap2/board-omap3beagle.c|5 - arch/arm/mach-omap2/board-omap3pandora.c |9 + arch/arm/mach-omap2/board-overo.c |3 arch/arm/mach-omap2/devices.c | 108 arch/arm/mach-omap2/mmc-twl4030.c | 186 arch/arm/mach-omap2/mmc-twl4030.h |6 + arch/arm/mach-omap2/mux.c | 27 arch/arm/mach-omap2/prcm.c | 14 ++ arch/arm/mach-omap2/usb-musb.c | 185 arch/arm/plat-omap/devices.c |3 arch/arm/plat-omap/include/mach/control.h |9 + arch/arm/plat-omap/include/mach/mmc.h |2 arch/arm/plat-omap/include/mach/mux.h | 13 ++ arch/arm/plat-omap/include/mach/omap34xx.h | 27 arch/arm/plat-omap/include/mach/usb.h |8 + 18 files changed, 549 insertions(+), 62 deletions(-) create mode 100644 arch/arm/mach-omap2/usb-musb.c -- Signature -- 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
What did omap2_disp_get_dss morph into?
I am trying to get the TI accelerated video driver to build against the current DSS2 kernel image, and I think I am this close || to getting it to go, but I am missing a pair of functions: omap2_disp_get_dss and omap2_disp_put_dss. Obviously, they've changed into something else - what did they morph into? -- 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.6.29-rc7-omap] twl4030-regulator: list more VAUX4 voltages
From: David Brownell
The VAUX4 voltage table scrolls onto a second page in many versions
of the TWL4030 family manuals. This doesn't mean we should ignore
those values! Some boards use the (fully supported) 2.8V setting.
Signed-off-by: David Brownell
---
Please apply to both the regulator-next and OMAP trees.
drivers/regulator/twl4030-regulator.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -229,6 +229,8 @@ static const u16 VAUX3_VSEL_table[] = {
static const u16 VAUX4_VSEL_table[] = {
700, 1000, 1200, UNSUP(1300),
1500, 1800, UNSUP(1850), 2500,
+ UNSUP(2600), 2800, UNSUP(2850), UNSUP(3000),
+ UNSUP(3150), UNSUP(3150), UNSUP(3150), UNSUP(3150),
};
static const u16 VMMC1_VSEL_table[] = {
1850, 2850, 3000, 3150,
--
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] [PATCH v2] OMAP: Store reboot mode in scratchpad on OMAP34xx
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 73b65cde9647508313b3d686dff0f3d1d92482d1 PatchWorks http://patchwork.kernel.org/patch/10718/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=73b65cde9647508313b3d686dff0f3d1d92482d1 -- 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/6] RX51: adjust hsmmc info
* David Brownell [090310 10:58]:
> On Tuesday 10 March 2009, Adrian Hunter wrote:
> > @@ -52,16 +52,20 @@ static struct platform_device *rx51_flash_devices[] = {
> >
> > static struct twl4030_hsmmc_info mmc[] __initdata = {
> > {
> > + .name = "external",
> > .mmc= 1,
> > - .wires = 8,
> > + .wires = 4,
> > + .cover_only = true,
> > .gpio_cd= 160,
> > .gpio_wp= -EINVAL,
> > },
> > {
> > + .name = "internal",
> > .mmc= 2,
> > .wires = 8,
>
> Ack on all the changes above ...
>
>
> > .gpio_cd= -EINVAL,
> > .gpio_wp= -EINVAL,
> > + .vsim_18v = true,
>
> ... but not that one.
>
> > },
> > {} /* Terminator */
> > };
>
>
Applied this too except for the vsim_18v.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OMAP: mmc-twl4030 add cover switch
* David Brownell [090310 10:51]:
> On Tuesday 10 March 2009, Adrian Hunter wrote:
> > >From 1667cd29afa90d041c0782223253835e6bc25b18 Mon Sep 17 00:00:00 2001
> > From: Adrian Hunter
> > Date: Mon, 26 Jan 2009 13:14:28 +0200
> > Subject: [PATCH] OMAP: mmc-twl4030 add cover switch
> >
> > Allow a cover switch to be used to cause a rescan of the
> > MMC slot.
> >
> > Signed-off-by: Adrian Hunter
>
> Acked-by: David Brownell
>
> Because a cover switch is not the same as a card detect switch...
Pushed this too after after editing the header change to apply.
Tony
> > ---
> > arch/arm/mach-omap2/mmc-twl4030.c | 13 -
> > arch/arm/mach-omap2/mmc-twl4030.h |1 +
> > 2 files changed, 13 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
> > b/arch/arm/mach-omap2/mmc-twl4030.c
> > index 736b039..a58deba 100644
> > --- a/arch/arm/mach-omap2/mmc-twl4030.c
> > +++ b/arch/arm/mach-omap2/mmc-twl4030.c
> > @@ -105,6 +105,14 @@ static int twl_mmc_get_ro(struct device *dev, int slot)
> > return gpio_get_value_cansleep(mmc->slots[0].gpio_wp);
> > }
> >
> > +static int twl_mmc_get_cover_state(struct device *dev, int slot)
> > +{
> > + struct omap_mmc_platform_data *mmc = dev->platform_data;
> > +
> > + /* NOTE: assumes card detect signal is active-low */
> > + return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
> > +}
> > +
> > /*
> > * MMC Slot Initialization.
> > */
> > @@ -427,7 +435,10 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
> > *controllers)
> >
> > mmc->slots[0].switch_pin = c->gpio_cd;
> > mmc->slots[0].card_detect_irq = gpio_to_irq(c->gpio_cd);
> > - mmc->slots[0].card_detect = twl_mmc_card_detect;
> > + if (c->cover_only)
> > + mmc->slots[0].get_cover_state =
> > twl_mmc_get_cover_state;
> > + else
> > + mmc->slots[0].card_detect = twl_mmc_card_detect;
> > } else
> > mmc->slots[0].switch_pin = -EINVAL;
> >
> > diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
> > b/arch/arm/mach-omap2/mmc-twl4030.h
> > index 087a969..e87bc8d 100644
> > --- a/arch/arm/mach-omap2/mmc-twl4030.h
> > +++ b/arch/arm/mach-omap2/mmc-twl4030.h
> > @@ -12,6 +12,7 @@ struct twl4030_hsmmc_info {
> > booltransceiver;/* MMC-2 option */
> > boolext_clock; /* use external pin for input clock */
> > boolvsim_18v; /* MMC-2 option */
> > + boolcover_only; /* No card detect - just cover switch */
> > int gpio_cd;/* or -EINVAL */
> > int gpio_wp;/* or -EINVAL */
> > struct device *dev; /* returned: pointer to mmc adapter */
> > --
> > 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
[APPLIED] > [PATCH] OMAP: mmc-twl4030 allow arbitrary slot names
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 84a26c2ee36fc899901c08ec0458be1d4999e8b5 PatchWorks http://patchwork.kernel.org/patch/10842/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=84a26c2ee36fc899901c08ec0458be1d4999e8b5 -- 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] > [PATCH] OMAP: mmc-twl4030 fix name buffer length
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 9ed678812ff0a8c42884ce5179b0ac34e3d0c995 PatchWorks http://patchwork.kernel.org/patch/10840/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=9ed678812ff0a8c42884ce5179b0ac34e3d0c995 -- 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] OMAP: McBSP: Do not enable or disable clocks on failed path
> Race here? See, McBSP is marked free before disabling the clocks and > thus omap_mcbsp_request can start enabling them. So should you keep > clock disabling after test for mcbsp->free as here now but mark McBSP > free only after clocks are disabled? > > I think you should send this as an separate fix since this should go to > the upstream also. Good comment... why do I always do everything in such a hurry, without thinking any =) Either that or leave clock disabling within the spin_lock covered code? (probably risky business) - Eero -- 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/6] RX51: adjust hsmmc info
On Tuesday 10 March 2009, Adrian Hunter wrote:
> @@ -52,16 +52,20 @@ static struct platform_device *rx51_flash_devices[] = {
>
> static struct twl4030_hsmmc_info mmc[] __initdata = {
> {
> + .name = "external",
> .mmc= 1,
> - .wires = 8,
> + .wires = 4,
> + .cover_only = true,
> .gpio_cd= 160,
> .gpio_wp= -EINVAL,
> },
> {
> + .name = "internal",
> .mmc= 2,
> .wires = 8,
Ack on all the changes above ...
> .gpio_cd= -EINVAL,
> .gpio_wp= -EINVAL,
> + .vsim_18v = true,
... but not that one.
> },
> {} /* Terminator */
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] OMAP: mmc-twl4030 allow arbitrary slot names
On Tuesday 10 March 2009, Adrian Hunter wrote:
> >From 4c4a97595cab39443a85517c66bc26f5c2a9cae3 Mon Sep 17 00:00:00 2001
> From: Adrian Hunter
> Date: Fri, 30 Jan 2009 11:10:19 +0200
> Subject: [PATCH] OMAP: mmc-twl4030 allow arbitrary slot names
>
> Signed-off-by: Adrian Hunter
Acked-by: David Brownell
Those current slot names are sort of useless, eh?
Actually the MMC framework itself is no help here. If for
example "mmcblk0" always came from host "mmc0" names would
work a lot more smoothly. Instead, "mmcblk0" comes from
the first card to be detected ... it might be from "mmc1"
on one boot, "mmc0" on the next, "mmc2" on a third boot.
> ---
> arch/arm/mach-omap2/mmc-twl4030.c |5 -
> arch/arm/mach-omap2/mmc-twl4030.h |1 +
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
> b/arch/arm/mach-omap2/mmc-twl4030.c
> index a58deba..8fc8e84 100644
> --- a/arch/arm/mach-omap2/mmc-twl4030.c
> +++ b/arch/arm/mach-omap2/mmc-twl4030.c
> @@ -419,7 +419,10 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
> *controllers)
> return;
> }
>
> - sprintf(twl->name, "mmc%islot%i", c->mmc, 1);
> + if (c->name)
> + strncpy(twl->name, c->name, HSMMC_NAME_LEN);
> + else
> + sprintf(twl->name, "mmc%islot%i", c->mmc, 1);
> mmc->slots[0].name = twl->name;
> mmc->nr_slots = 1;
> mmc->slots[0].wires = c->wires;
> diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
> b/arch/arm/mach-omap2/mmc-twl4030.h
> index e87bc8d..69dbbc1 100644
> --- a/arch/arm/mach-omap2/mmc-twl4030.h
> +++ b/arch/arm/mach-omap2/mmc-twl4030.h
> @@ -15,6 +15,7 @@ struct twl4030_hsmmc_info {
> boolcover_only; /* No card detect - just cover switch */
> int gpio_cd;/* or -EINVAL */
> int gpio_wp;/* or -EINVAL */
> + char*name; /* or NULL for default */
> struct device *dev; /* returned: pointer to mmc adapter */
> };
>
> --
> 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: [PATCH 3/6] OMAP: mmc-twl4030 add cover switch
On Tuesday 10 March 2009, Adrian Hunter wrote:
> >From 1667cd29afa90d041c0782223253835e6bc25b18 Mon Sep 17 00:00:00 2001
> From: Adrian Hunter
> Date: Mon, 26 Jan 2009 13:14:28 +0200
> Subject: [PATCH] OMAP: mmc-twl4030 add cover switch
>
> Allow a cover switch to be used to cause a rescan of the
> MMC slot.
>
> Signed-off-by: Adrian Hunter
Acked-by: David Brownell
Because a cover switch is not the same as a card detect switch...
> ---
> arch/arm/mach-omap2/mmc-twl4030.c | 13 -
> arch/arm/mach-omap2/mmc-twl4030.h |1 +
> 2 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
> b/arch/arm/mach-omap2/mmc-twl4030.c
> index 736b039..a58deba 100644
> --- a/arch/arm/mach-omap2/mmc-twl4030.c
> +++ b/arch/arm/mach-omap2/mmc-twl4030.c
> @@ -105,6 +105,14 @@ static int twl_mmc_get_ro(struct device *dev, int slot)
> return gpio_get_value_cansleep(mmc->slots[0].gpio_wp);
> }
>
> +static int twl_mmc_get_cover_state(struct device *dev, int slot)
> +{
> + struct omap_mmc_platform_data *mmc = dev->platform_data;
> +
> + /* NOTE: assumes card detect signal is active-low */
> + return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
> +}
> +
> /*
> * MMC Slot Initialization.
> */
> @@ -427,7 +435,10 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
> *controllers)
>
> mmc->slots[0].switch_pin = c->gpio_cd;
> mmc->slots[0].card_detect_irq = gpio_to_irq(c->gpio_cd);
> - mmc->slots[0].card_detect = twl_mmc_card_detect;
> + if (c->cover_only)
> + mmc->slots[0].get_cover_state =
> twl_mmc_get_cover_state;
> + else
> + mmc->slots[0].card_detect = twl_mmc_card_detect;
> } else
> mmc->slots[0].switch_pin = -EINVAL;
>
> diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
> b/arch/arm/mach-omap2/mmc-twl4030.h
> index 087a969..e87bc8d 100644
> --- a/arch/arm/mach-omap2/mmc-twl4030.h
> +++ b/arch/arm/mach-omap2/mmc-twl4030.h
> @@ -12,6 +12,7 @@ struct twl4030_hsmmc_info {
> booltransceiver;/* MMC-2 option */
> boolext_clock; /* use external pin for input clock */
> boolvsim_18v; /* MMC-2 option */
> + boolcover_only; /* No card detect - just cover switch */
> int gpio_cd;/* or -EINVAL */
> int gpio_wp;/* or -EINVAL */
> struct device *dev; /* returned: pointer to mmc adapter */
> --
> 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: [PATCH 2/6] OMAP: mmc-twl4030 support VSIM is VMMC2_IO
On Tuesday 10 March 2009, Adrian Hunter wrote:
> @@ -61,6 +65,7 @@ static struct twl_mmc_controller {
> struct omap_mmc_platform_data *mmc;
> u8 twl_vmmc_dev_grp;
> u8 twl_mmc_dedicated;
> + boolvsim_18v;
> charname[HSMMC_NAME_LEN + 1];
> } hsmmc[OMAP34XX_NR_MMC] = {
> {
I have an alternate approach to your patches #2, and #6 ...
basically, as part of switching the mmc-twl4030 glue over to
the regulator framework, each MMC device can have two named
supplies. (And the glue should work with PMICs other than
just the twl4030 family chips.)
So an eMMC chip with both power rails switchable would set up
one for Vcc, and a second for VccQ ... which need not be VSIM,
and need not even use a twl4030. MMC2 and MMC3 would be able
to switch VccQ on after Vcc, for eMMC ... or similarly for an
SDIO chip with a switchable regulator.
So your #2 patch won't be needed, since the second supply would
be handled in a more general way; ditto #6. Some of the other
patches will also be affected.
I'll send patches implementing this as soon as I get them
working on one more board.
- Dave
--
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/6] OMAP: mmc-twl4030 fix name buffer length
On Tuesday 10 March 2009, Adrian Hunter wrote:
> >From 60238a3a80b5be3e1843a049b39eabf729c315aa Mon Sep 17 00:00:00 2001
> From: Adrian Hunter
> Date: Thu, 22 Jan 2009 17:58:04 +0200
> Subject: [PATCH] OMAP: mmc-twl4030 fix name buffer length
>
> Add 1 to buffer length for null terminator.
>
> Signed-off-by: Adrian Hunter
Acked-by: David Brownell
An endless off-by-one bug ...
> ---
> arch/arm/mach-omap2/mmc-twl4030.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
> b/arch/arm/mach-omap2/mmc-twl4030.c
> index 33e5b9b..aeaab5a 100644
> --- a/arch/arm/mach-omap2/mmc-twl4030.c
> +++ b/arch/arm/mach-omap2/mmc-twl4030.c
> @@ -61,7 +61,7 @@ static struct twl_mmc_controller {
> struct omap_mmc_platform_data *mmc;
> u8 twl_vmmc_dev_grp;
> u8 twl_mmc_dedicated;
> - charname[HSMMC_NAME_LEN];
> + charname[HSMMC_NAME_LEN + 1];
> } hsmmc[OMAP34XX_NR_MMC] = {
> {
> .twl_vmmc_dev_grp = VMMC1_DEV_GRP,
> --
> 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
[PATCH] Remove fclk check for cpuidle
This patch removes the check to see if some functional clocks are still
enabled before entering sleep.
Signed-off-by: Peter 'p2' De Schrijver
---
arch/arm/mach-omap2/pm34xx.c | 46 --
1 files changed, 0 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e12ff2a..008a4d2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -453,58 +453,12 @@ void omap_sram_idle(void)
omap2_clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
}
-/*
- * Check if functional clocks are enabled before entering
- * sleep. This function could be behind CONFIG_PM_DEBUG
- * when all drivers are configuring their sysconfig registers
- * properly and using their clocks properly.
- */
-static int omap3_fclks_active(void)
-{
- u32 fck_core1 = 0, fck_core3 = 0, fck_sgx = 0, fck_dss = 0,
- fck_cam = 0, fck_per = 0, fck_usbhost = 0;
-
- fck_core1 = cm_read_mod_reg(CORE_MOD,
- CM_FCLKEN1);
- if (omap_rev() > OMAP3430_REV_ES1_0) {
- fck_core3 = cm_read_mod_reg(CORE_MOD,
- OMAP3430ES2_CM_FCLKEN3);
- fck_sgx = cm_read_mod_reg(OMAP3430ES2_SGX_MOD,
- CM_FCLKEN);
- fck_usbhost = cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD,
- CM_FCLKEN);
- } else
- fck_sgx = cm_read_mod_reg(GFX_MOD,
- OMAP3430ES2_CM_FCLKEN3);
- fck_dss = cm_read_mod_reg(OMAP3430_DSS_MOD,
- CM_FCLKEN);
- fck_cam = cm_read_mod_reg(OMAP3430_CAM_MOD,
- CM_FCLKEN);
- fck_per = cm_read_mod_reg(OMAP3430_PER_MOD,
- CM_FCLKEN);
-
- /* Ignore UART clocks. These are handled by UART core (serial.c) */
- fck_core1 &= ~(OMAP3430_EN_UART1 | OMAP3430_EN_UART2);
- fck_per &= ~OMAP3430_EN_UART3;
-
- /* Ignore GPIO clocks. Handled by GPIO prepare-idle hooks */
- fck_per &= ~(OMAP3430_EN_GPIO2 | OMAP3430_EN_GPIO3 |
-OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 | OMAP3430_EN_GPIO6);
-
- if (fck_core1 | fck_core3 | fck_sgx | fck_dss |
- fck_cam | fck_per | fck_usbhost)
- return 1;
- return 0;
-}
-
int omap3_can_sleep(void)
{
if (!enable_dyn_sleep)
return 0;
if (!omap_uart_can_sleep())
return 0;
- if (omap3_fclks_active())
- return 0;
if (atomic_read(&sleep_block) > 0)
return 0;
return 1;
--
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
[PATCH] Add new C state
This patch introduces a new C state which allows MPU to go to WFI but keeps
the core domain active. This offers a much better wakeup latency (3us vs
10s of us for the current C1) at the cost of a higher power consumption.
Signed-off-by: Peter 'p2' De Schrijver
---
arch/arm/mach-omap2/cpuidle34xx.c | 119 +++-
1 files changed, 76 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 62fbb2e..5565aa7 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -33,13 +34,14 @@
#ifdef CONFIG_CPU_IDLE
-#define OMAP3_MAX_STATES 7
+#define OMAP3_MAX_STATES 8
#define OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */
-#define OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */
-#define OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */
-#define OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */
-#define OMAP3_STATE_C5 5 /* C5 - MPU OFF + Core RET */
-#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core OFF */
+#define OMAP3_STATE_C2 2 /* C2 - MPU WFI + Core inactive */
+#define OMAP3_STATE_C3 3 /* C2 - MPU CSWR + Core inactive */
+#define OMAP3_STATE_C4 4 /* C3 - MPU OFF + Core iactive */
+#define OMAP3_STATE_C5 5 /* C4 - MPU RET + Core RET */
+#define OMAP3_STATE_C6 6 /* C5 - MPU OFF + Core RET */
+#define OMAP3_STATE_C7 7 /* C6 - MPU OFF + Core OFF */
struct omap3_processor_cx {
u8 valid;
@@ -63,6 +65,16 @@ static int omap3_idle_bm_check(void)
return 0;
}
+static int _cpuidle_allow_idle(struct powerdomain *pwrdm, struct clockdomain
*clkdm)
+{
+ omap2_clkdm_allow_idle(clkdm);
+}
+
+static int _cpuidle_deny_idle(struct powerdomain *pwrdm, struct clockdomain
*clkdm)
+{
+ omap2_clkdm_deny_idle(clkdm);
+}
+
/**
* omap3_enter_idle - Programs OMAP3 to enter the specified state
* @dev: cpuidle device
@@ -99,9 +111,19 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
if (omap_irq_pending())
goto return_sleep_time;
+ if (cx->type == OMAP3_STATE_C1) {
+ pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
+ pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ }
+
/* Execute ARM wfi */
omap_sram_idle();
+ if (cx->type == OMAP3_STATE_C1) {
+ pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
+ pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ }
+
return_sleep_time:
getnstimeofday(&ts_postidle);
ts_idle = timespec_sub(ts_postidle, ts_preidle);
@@ -140,79 +162,90 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
/* omap3_init_power_states - Initialises the OMAP3 specific C states.
*
* Below is the desciption of each C state.
- * C1 . MPU WFI + Core active
- * C2 . MPU CSWR + Core active
- * C3 . MPU OFF + Core active
- * C4 . MPU CSWR + Core CSWR
- * C5 . MPU OFF + Core CSWR
- * C6 . MPU OFF + Core OFF
+ * C1 . MPU WFI + Core active
+ * C2 . MPU WFI + Core inactive
+ * C3 . MPU CSWR + Core inactive
+ * C4 . MPU OFF + Core inactive
+ * C5 . MPU CSWR + Core CSWR
+ * C6 . MPU OFF + Core CSWR
+ * C7 . MPU OFF + Core OFF
*/
void omap_init_power_states(void)
{
/* C1 . MPU WFI + Core active */
omap3_power_states[OMAP3_STATE_C1].valid = 1;
omap3_power_states[OMAP3_STATE_C1].type = OMAP3_STATE_C1;
- omap3_power_states[OMAP3_STATE_C1].sleep_latency = 10;
- omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 10;
- omap3_power_states[OMAP3_STATE_C1].threshold = 30;
+ omap3_power_states[OMAP3_STATE_C1].sleep_latency = 2;
+ omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 2;
+ omap3_power_states[OMAP3_STATE_C1].threshold = 5;
omap3_power_states[OMAP3_STATE_C1].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C1].core_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C1].flags = CPUIDLE_FLAG_TIME_VALID;
- /* C2 . MPU CSWR + Core active */
+ /* C2 . MPU WFI + Core inactive */
omap3_power_states[OMAP3_STATE_C2].valid = 1;
omap3_power_states[OMAP3_STATE_C2].type = OMAP3_STATE_C2;
- omap3_power_states[OMAP3_STATE_C2].sleep_latency = 50;
- omap3_power_states[OMAP3_STATE_C2].wakeup_latency = 50;
- omap3_power_states[OMAP3_STATE_C2].threshold = 300;
- omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_RET;
+ omap3_power_states[OMAP3_STATE_C2].sleep_latency = 10;
+ omap3_power_states[OMAP3_STATE_C2].wakeup_latency = 10;
+ omap3_power_states[OMAP3_STATE_C2].threshold = 30;
+ omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
- omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID |
-
Re: Problems in cpuidle
"Premi, Sanjeev" writes:
>> -Original Message-
>> From: Högander Jouni [mailto:jouni.hogan...@nokia.com]
>> Sent: Monday, March 09, 2009 3:36 PM
>> To: Premi, Sanjeev
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: Problems in cpuidle
>>
>> "ext Premi, Sanjeev" writes:
>>
>> > While working with cpuidle, I have come across these problems.
>> > I am also working on the solutions, but would be good to hear more
>> > thoughts.
>> >
>> > 1) The flag 'enable_dyn_sleep' is honoured only in
>> omap3_idle_bm_check()
>> >but in the C1 state, omap3_enter_idle() is invoked directly.
>> >So, the system can transition to deeper idle state(s)
>> >
>> >Same is the case with 'sleep_block'.
>> >
>> >Possible Solutions:
>> > a) Call omap3_can_sleep() in omap3_enter_idle().
>> > This makes omap3_idle_bm_check() redundant; and
>> can be removed.
>> >
>> > b) Make single entry point for all idle states
>> > But would be an overkill for C1 state.
>> >
>> > c) Change omap3_can_sleep() to check for omap_uart_can_sleep()
>> > and omap3_fclks_active() only.
>> > Move check for 'enable_dyn_sleep' and 'sleep_block' into
>> > omap3_enter_idle()
>> >
>> > I believe (c) would be the most optimal.
>>
>> Selecting (c) will break traditional pm_idle. Current plan is
>> to add one more C state (C1) which would prevent mpu/core
>> sleep transitions. Then remove fclk_active check completely.
>
> [sp] I meant doing the same for pm_idle as well.
> Also, the new cstate will not help with 'sleep' block.
>
> The proposed change look like:
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> b/arch/arm/mach-omap2/cpuidle34xx
> index 7fc3cb3..c25158c 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -82,6 +82,11 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
> /* Used to keep track of the total time in idle */
> getnstimeofday(&ts_preidle);
>
> + if (!enable_dyn_sleep)
> + goto return_sleep_time;
> + if (atomic_read(&sleep_block) > 0)
> + goto return_sleep_time;
> +
> /*
> * Adjust the idle state (if required).
> * Also, ensure that usage statistics of correct state are updated.
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 0716d60..5c7819a 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -476,14 +476,10 @@ static int omap3_fclks_active(void)
>
> int omap3_can_sleep(void)
> {
> - if (!enable_dyn_sleep)
> - return 0;
> if (!omap_uart_can_sleep())
> return 0;
> if (omap3_fclks_active())
> return 0;
> - if (atomic_read(&sleep_block) > 0)
> - return 0;
> return 1;
> }
>
> @@ -534,6 +530,11 @@ err:
>
> static void omap3_pm_idle(void)
> {
> + if (!enable_dyn_sleep)
> + return;
> + if (atomic_read(&sleep_block) > 0)
> + return;
> +
> local_irq_disable();
> local_fiq_disable();
>
Sanjeev,
I think it's cleaner to just make all the states go through the 'bm_check',
so the standard PM idle and CPUidle use the same paths.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP: McBSP: Do not enable or disable clocks on failed path
On Mon, 9 Mar 2009 08:05:12 +0100
"Nurkkala Eero.An (EXT-Offcode/Oulu)"
wrote:
> From: Eero Nurkkala
>
> McBSP clocks are being double enabled in the event the
> McBSP is already active. Also, they are unnecessarily
> disabled when there's no active McBSP in use. Fix this
> phenomenom by enabling and disabling the clocks at a
> proper location.
>
> @@ -226,9 +226,6 @@ int omap_mcbsp_request(unsigned int id)
> if (mcbsp->pdata && mcbsp->pdata->ops &&
> mcbsp->pdata->ops->request) mcbsp->pdata->ops->request(id);
>
> - for (i = 0; i < mcbsp->num_clks; i++)
> - clk_enable(mcbsp->clks[i]);
> -
> spin_lock(&mcbsp->lock);
> if (!mcbsp->free) {
> dev_err(mcbsp->dev, "McBSP%d is currently in use\n",
> @@ -240,6 +237,9 @@ int omap_mcbsp_request(unsigned int id)
> mcbsp->free = 0;
> spin_unlock(&mcbsp->lock);
>
> + for (i = 0; i < mcbsp->num_clks; i++)
> + clk_enable(mcbsp->clks[i]);
> +
Valid fix.
> @@ -319,9 +319,6 @@ void omap_mcbsp_free(unsigned int id)
> if (mcbsp->pdata && mcbsp->pdata->ops &&
> mcbsp->pdata->ops->free) mcbsp->pdata->ops->free(id);
>
> - for (i = mcbsp->num_clks - 1; i >= 0; i--)
> - clk_disable(mcbsp->clks[i]);
> -
> spin_lock(&mcbsp->lock);
> if (mcbsp->free) {
> dev_err(mcbsp->dev, "McBSP%d was not reserved\n",
> @@ -333,6 +330,9 @@ void omap_mcbsp_free(unsigned int id)
> mcbsp->free = 1;
> spin_unlock(&mcbsp->lock);
>
> + for (i = mcbsp->num_clks - 1; i >= 0; i--)
> + clk_disable(mcbsp->clks[i]);
> +
Race here? See, McBSP is marked free before disabling the clocks and
thus omap_mcbsp_request can start enabling them. So should you keep
clock disabling after test for mcbsp->free as here now but mark McBSP
free only after clocks are disabled?
I think you should send this as an separate fix since this should go to
the upstream also.
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: McBSP: Always maintain McBSP fclk while active
On Mon, 9 Mar 2009 08:05:11 +0100 "Nurkkala Eero.An (EXT-Offcode/Oulu)" wrote: > From: Eero Nurkkala > > McBSP fclk must be maintained for the duration of > audio playback or recording. Otherwise the fclk > may get autogated when the PER96M clk is no longer > required by other modules. This results in audio > playback being hang. Fix this phenomenom by > enabling the McBSP fclk clockactivity bit for > the entire active duration of McBSP usage > ... > w = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON); > - w &= ~(ENAWAKEUP | SIDLEMODE(0x03)); > - w |= (ENAWAKEUP | SIDLEMODE(0x02)); > + w &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY > (0x03)); > + w |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY > (0x01)); OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, w); > Looks like a valid change eventhough haven't tested the actual problem. Would it be possible with the PM branch and Beagle now? Jarkko -- 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: OMAP: Fix GPIO switch initial output state handling
Jani,
Please see my comments below.
On Tue, Mar 10, 2009 at 4:26 AM, Jani Nikula
wrote:
> The switchover to cross-platform GPIO interface unexpectedly caused all
> output GPIO switches to be set to high state by default, unlike the
> original OMAP code. Introduce a new GPIO switch flag to define the
> initial state. Unless the flag is set, the default is now low state.
>
> Also store the state of output switches directly into the switch struct
> instead of trying to read an output GPIO.
>
> Signed-off-by: Jani Nikula
> ---
> arch/arm/plat-omap/gpio-switch.c | 13 +
> arch/arm/plat-omap/include/mach/gpio-switch.h |1 +
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio-switch.c
> b/arch/arm/plat-omap/gpio-switch.c
> index 2b5665d..b278024 100644
> --- a/arch/arm/plat-omap/gpio-switch.c
> +++ b/arch/arm/plat-omap/gpio-switch.c
> @@ -286,12 +286,17 @@ static int __init new_switch(struct gpio_switch *sw)
>
>/* input: 1, output: 0 */
>direction = !(sw->flags & OMAP_GPIO_SWITCH_FLAG_OUTPUT);
> - if (direction)
> + if (direction) {
>gpio_direction_input(sw->gpio);
> - else
> - gpio_direction_output(sw->gpio, true);
> + sw->state = gpio_sw_get_state(sw);
> + } else {
> + int state = sw->state =
> + !!(sw->flags &
> OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_HIGH);
>
> - sw->state = gpio_sw_get_state(sw);
> + if (sw->flags & OMAP_GPIO_SWITCH_FLAG_INVERTED)
> + state = !state;
Using OMAP_GPIO_SWITCH_FLAG_INVERTED along with
OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_HIGH here is somewhat confusing to
me.
INIT_HIGH indicates the state of the gpio, not the state of the
switch. Why not ignore the OMAP_GPIO_SWITCH_FLAG_INVERTED all together
when setting up the switch. This way, the user does not have to think
twice. :)
> + gpio_direction_output(sw->gpio, state);
> + }
>
>r = 0;
>r |= device_create_file(&sw->pdev.dev, &dev_attr_state);
> diff --git a/arch/arm/plat-omap/include/mach/gpio-switch.h
> b/arch/arm/plat-omap/include/mach/gpio-switch.h
> index a143253..107d23f 100644
> --- a/arch/arm/plat-omap/include/mach/gpio-switch.h
> +++ b/arch/arm/plat-omap/include/mach/gpio-switch.h
> @@ -29,6 +29,7 @@
> #define OMAP_GPIO_SWITCH_TYPE_ACTIVITY 0x0002
> #define OMAP_GPIO_SWITCH_FLAG_INVERTED 0x0001
> #define OMAP_GPIO_SWITCH_FLAG_OUTPUT 0x0002
> +#define OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_HIGH 0x0004
>
> struct omap_gpio_switch {
>const char *name;
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
> Hans Verkuil wrote: >>> Sergio has posted earlier a patchset containing a driver for using the >>> ISP to process images from memory to memory. The ISP driver is used >>> roughly the same way as with the omap34xxcam and real sensors. The >>> interface towards the userspace offered by the driver, however, is >>> different, you probably saw it (preview and resizer wrappers). >>> >>> My opinion has been that the memory-to-memory operation of the ISP >>> should also offer V4L2 interface. V4L2, however, doesn't support such >>> devices at the moment. The only differences that I can see is that >>> >>> 1. the input is a video buffer instead of sensor and >>> >>> 2. the source format needs to be specified somehow since the ISP can >>> also do format conversion. So it's output and input at the same time. >>> >>> But if we had one video device per ISP, then memory-to-memory operation >>> would be just one... input or output or what? :) >>> >>> Earlier we were thinking of creating one device node for it. >> >> This sounds like a codec interface as 'described' here: >> >> http://www.xs4all.nl/~hverkuil/spec/v4l2.html#CODEC >> >> It would be a first for V4L2 to have a driver that can do this, but I >> agree >> that that would be a single device that has both 'output' and 'capture'. > > Ok. Although this work most probably will be left for future at this > point. > >>> Currently you can have just one device node using the ISP open. >>> omap34xxcam_open() calls isp_get() which fails if the ISP use count was >>> non-zero (means one). >>> >>> Or did I misunderstood something? >> >> Oh dear. Please don't use 'use counts'. It is perfectly acceptable and >> desirable to have multiple opens on the same video node. Only one file > >> Use counts are really bad and totally unnecessary. Only if another file >> handle is in streaming mode (and when using VIDIOC_S_PRIORITY) does it >> make >> sense to return -EBUSY for certain ioctls or read/write operations. >> Otherwise you shouldn't limit the user from opening the same device node >> as >> many times as he wants and use that to query the video device. > > ? > > Having a use count doesn't prevent multiple file handles nor otherwise > artificially limit functionality. We need to be able to shut down the > slaves when they are no longer needed. IMO having an use count to do > this is fine (unless otherwise proven). Yes, it is fine for such purposes. As long as it isn't abused to restrict functionality on subsequent opens. Several drivers use it for that, and that is NOT right. But it's OK for powersaving implementations. I should have mentioned that. > Also the camera driver does try_module_get() to the slaves when it's > opened by the first user. module_put() is called on those when the last > user goes away. This is to allow those modules to be unloaded? > We'd also like to get rid of the current way of directly telling the > slaves what their power state should be. Rather we'd like to tell the > slaves what's expected from them. This could translate to > open/release/streamon/streamoff commands. To be able to do this, the use > count is required --- unless this task is given to the slaves > (v4l2_subdevs). Sounds interesting. I would have to see a proposal or proof-of-concept code to determine how useful it is. It's however better to do this after the v4l2-subdev conversion. >> BTW, I looked at omap24xxcam_open(): data like fh->pix does *not* belong >> to >> the filehandle struct, it should be part of the top-level data >> structure. > > That's fixed in the omap34xxcam.c. :) Yay! >> You want to be able to do simple things like querying a video node for >> the >> currently selected format. You can't do that if the format is stored in >> the >> filehandle! E.g.: you are streaming and you want to run >> v4l2-ctl --get-fmt-video to check what video format is being used. >> Things >> like this must be supported by a well-written v4l2 driver. Again, sadly >> quite a few v4l2 drivers do this wrong as well :-( >> >> I also see that cam->users is not decreased by one if >> omap24xxcam_sensor_enable() fails. >> >> Note that I'm looking at the code in the v4l-dvb repository, the >> linux-omap >> git tree might have fixed that already. > > I'm afraid it's still there. Will fix that. OK. Thanks, 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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hans Verkuil wrote: Sergio has posted earlier a patchset containing a driver for using the ISP to process images from memory to memory. The ISP driver is used roughly the same way as with the omap34xxcam and real sensors. The interface towards the userspace offered by the driver, however, is different, you probably saw it (preview and resizer wrappers). My opinion has been that the memory-to-memory operation of the ISP should also offer V4L2 interface. V4L2, however, doesn't support such devices at the moment. The only differences that I can see is that 1. the input is a video buffer instead of sensor and 2. the source format needs to be specified somehow since the ISP can also do format conversion. So it's output and input at the same time. But if we had one video device per ISP, then memory-to-memory operation would be just one... input or output or what? :) Earlier we were thinking of creating one device node for it. This sounds like a codec interface as 'described' here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html#CODEC It would be a first for V4L2 to have a driver that can do this, but I agree that that would be a single device that has both 'output' and 'capture'. Ok. Although this work most probably will be left for future at this point. Currently you can have just one device node using the ISP open. omap34xxcam_open() calls isp_get() which fails if the ISP use count was non-zero (means one). Or did I misunderstood something? Oh dear. Please don't use 'use counts'. It is perfectly acceptable and desirable to have multiple opens on the same video node. Only one file Use counts are really bad and totally unnecessary. Only if another file handle is in streaming mode (and when using VIDIOC_S_PRIORITY) does it make sense to return -EBUSY for certain ioctls or read/write operations. Otherwise you shouldn't limit the user from opening the same device node as many times as he wants and use that to query the video device. ? Having a use count doesn't prevent multiple file handles nor otherwise artificially limit functionality. We need to be able to shut down the slaves when they are no longer needed. IMO having an use count to do this is fine (unless otherwise proven). Also the camera driver does try_module_get() to the slaves when it's opened by the first user. module_put() is called on those when the last user goes away. We'd also like to get rid of the current way of directly telling the slaves what their power state should be. Rather we'd like to tell the slaves what's expected from them. This could translate to open/release/streamon/streamoff commands. To be able to do this, the use count is required --- unless this task is given to the slaves (v4l2_subdevs). BTW, I looked at omap24xxcam_open(): data like fh->pix does *not* belong to the filehandle struct, it should be part of the top-level data structure. That's fixed in the omap34xxcam.c. :) You want to be able to do simple things like querying a video node for the currently selected format. You can't do that if the format is stored in the filehandle! E.g.: you are streaming and you want to run v4l2-ctl --get-fmt-video to check what video format is being used. Things like this must be supported by a well-written v4l2 driver. Again, sadly quite a few v4l2 drivers do this wrong as well :-( I also see that cam->users is not decreased by one if omap24xxcam_sensor_enable() fails. Note that I'm looking at the code in the v4l-dvb repository, the linux-omap git tree might have fixed that already. I'm afraid it's still there. Will fix that. Thanks. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
[PATCH 6/6] OMAP: mmc-twl4030: Add VAUX3 support
>From a9cdb13f11c6f38680a4bec27300ed4c4709418f Mon Sep 17 00:00:00 2001
From: Jarkko Lavinen
Date: Wed, 25 Feb 2009 15:04:20 +0200
Subject: [PATCH] OMAP: mmc-twl4030: Add VAUX3 support
Allow overriding of VMMC2 regulator for MMC2 and use VAUX3 instead.
Signed-off-by: Jarkko Lavinen
Signed-off-by: Adrian Hunter
---
arch/arm/mach-omap2/board-rx51-flash.c |2 +
arch/arm/mach-omap2/mmc-twl4030.c | 106 ++--
arch/arm/mach-omap2/mmc-twl4030.h |1 +
3 files changed, 76 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-flash.c
b/arch/arm/mach-omap2/board-rx51-flash.c
index 20fe242..7060d26 100644
--- a/arch/arm/mach-omap2/board-rx51-flash.c
+++ b/arch/arm/mach-omap2/board-rx51-flash.c
@@ -20,6 +20,7 @@
#include "mmc-twl4030.h"
#defineRX51_FLASH_CS 0
+#defineVAUX3_DEV_GRP 0x1F
extern struct mtd_partition n800_partitions[ONENAND_MAX_PARTITIONS];
extern int n800_onenand_setup(void __iomem *onenand_base, int freq);
@@ -66,6 +67,7 @@ static struct twl4030_hsmmc_info mmc[] __initdata = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.vsim_18v = true,
+ .vmmc_dev_grp = VAUX3_DEV_GRP,
},
{} /* Terminator */
};
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 8fc8e84..208ff43 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -31,30 +31,34 @@
#define LDO_CLR0x00
#define VSEL_S2_CLR0x40
+#define VMMC_DEV_GRP_P10x20
+#define DEDICATED_OFFSET 3
+#define VMMC_DEV_GRP(c)(c->twl_vmmc_dev_grp)
+#define VAUX3_DEV_GRP 0x1F
#define VMMC1_DEV_GRP 0x27
-#define VMMC1_CLR 0x00
+#define VMMC2_DEV_GRP 0x2B
+#define VSIM_DEV_GRP 0x37
+
#define VMMC1_315V 0x03
#define VMMC1_300V 0x02
#define VMMC1_285V 0x01
#define VMMC1_185V 0x00
-#define VMMC1_DEDICATED0x2A
-#define VMMC2_DEV_GRP 0x2B
-#define VMMC2_CLR 0x40
#define VMMC2_315V 0x0c
#define VMMC2_300V 0x0b
#define VMMC2_285V 0x0a
#define VMMC2_280V 0x09
#define VMMC2_260V 0x08
#define VMMC2_185V 0x06
-#define VMMC2_DEDICATED0x2E
-#define VMMC_DEV_GRP_P10x20
+#define VAUX3_300V 0x04
+#define VAUX3_280V 0x03
+#define VAUX3_250V 0x02
+#define VAUX3_180V 0x01
+#define VAUX3_150V 0x00
-#define VSIM_DEV_GRP 0x37
#define VSIM_18V 0x03
-#define VSIM_DEDICATED 0x3A
static u16 control_pbias_offset;
static u16 control_devconf1_offset;
@@ -64,17 +68,14 @@ static u16 control_devconf1_offset;
static struct twl_mmc_controller {
struct omap_mmc_platform_data *mmc;
u8 twl_vmmc_dev_grp;
- u8 twl_mmc_dedicated;
boolvsim_18v;
charname[HSMMC_NAME_LEN + 1];
} hsmmc[OMAP34XX_NR_MMC] = {
{
.twl_vmmc_dev_grp = VMMC1_DEV_GRP,
- .twl_mmc_dedicated = VMMC1_DEDICATED,
},
{
.twl_vmmc_dev_grp = VMMC2_DEV_GRP,
- .twl_mmc_dedicated = VMMC2_DEDICATED,
},
};
@@ -188,10 +189,31 @@ static int twl_mmc_resume(struct device *dev, int slot)
|MMC_VDD_25_26|MMC_VDD_26_27|MMC_VDD_27_28 \
|MMC_VDD_28_29|MMC_VDD_29_30|MMC_VDD_30_31|MMC_VDD_31_32)
+static int twl_mmc_set_regulator(u8 vmmc_dev_grp, u8 vmmc)
+{
+ int ret;
+
+ ret = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ VMMC_DEV_GRP_P1, vmmc_dev_grp);
+
+ if (ret)
+ return ret;
+
+ ret = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ vmmc, vmmc_dev_grp + DEDICATED_OFFSET);
+ return ret;
+}
+
+static int twl_mmc_shutdown_regulator(u8 vmmc_dev_grp)
+{
+ return twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ LDO_CLR, vmmc_dev_grp);
+}
+
static int twl_mmc_set_voltage(struct twl_mmc_controller *c, int vdd)
{
int ret;
- u8 vmmc = 0, dev_grp_val;
+ u8 vmmc = 0;
if (!vdd)
goto doit;
@@ -221,6 +243,32 @@ static int twl_mmc_set_voltage(struct twl_mmc_controller
*c, int vdd)
default:
return -EINVAL;
}
+ } else if (c->twl_vmmc_dev_grp == VAUX3_DEV_GRP) {
+ /* VAUX3: max 200 mA */
+ switch (1 << vdd) {
+ case MMC_VDD_165_195:
+ vmmc = VAUX3_180V;
+ break;
+
[PATCH 4/6] OMAP: mmc-twl4030 allow arbitrary slot names
>From 4c4a97595cab39443a85517c66bc26f5c2a9cae3 Mon Sep 17 00:00:00 2001
From: Adrian Hunter
Date: Fri, 30 Jan 2009 11:10:19 +0200
Subject: [PATCH] OMAP: mmc-twl4030 allow arbitrary slot names
Signed-off-by: Adrian Hunter
---
arch/arm/mach-omap2/mmc-twl4030.c |5 -
arch/arm/mach-omap2/mmc-twl4030.h |1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index a58deba..8fc8e84 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -419,7 +419,10 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
return;
}
- sprintf(twl->name, "mmc%islot%i", c->mmc, 1);
+ if (c->name)
+ strncpy(twl->name, c->name, HSMMC_NAME_LEN);
+ else
+ sprintf(twl->name, "mmc%islot%i", c->mmc, 1);
mmc->slots[0].name = twl->name;
mmc->nr_slots = 1;
mmc->slots[0].wires = c->wires;
diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
b/arch/arm/mach-omap2/mmc-twl4030.h
index e87bc8d..69dbbc1 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -15,6 +15,7 @@ struct twl4030_hsmmc_info {
boolcover_only; /* No card detect - just cover switch */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
+ char*name; /* or NULL for default */
struct device *dev; /* returned: pointer to mmc adapter */
};
--
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
[PATCH 1/6] OMAP: mmc-twl4030 fix name buffer length
>From 60238a3a80b5be3e1843a049b39eabf729c315aa Mon Sep 17 00:00:00 2001
From: Adrian Hunter
Date: Thu, 22 Jan 2009 17:58:04 +0200
Subject: [PATCH] OMAP: mmc-twl4030 fix name buffer length
Add 1 to buffer length for null terminator.
Signed-off-by: Adrian Hunter
---
arch/arm/mach-omap2/mmc-twl4030.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 33e5b9b..aeaab5a 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -61,7 +61,7 @@ static struct twl_mmc_controller {
struct omap_mmc_platform_data *mmc;
u8 twl_vmmc_dev_grp;
u8 twl_mmc_dedicated;
- charname[HSMMC_NAME_LEN];
+ charname[HSMMC_NAME_LEN + 1];
} hsmmc[OMAP34XX_NR_MMC] = {
{
.twl_vmmc_dev_grp = VMMC1_DEV_GRP,
--
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
[PATCH 3/6] OMAP: mmc-twl4030 add cover switch
>From 1667cd29afa90d041c0782223253835e6bc25b18 Mon Sep 17 00:00:00 2001
From: Adrian Hunter
Date: Mon, 26 Jan 2009 13:14:28 +0200
Subject: [PATCH] OMAP: mmc-twl4030 add cover switch
Allow a cover switch to be used to cause a rescan of the
MMC slot.
Signed-off-by: Adrian Hunter
---
arch/arm/mach-omap2/mmc-twl4030.c | 13 -
arch/arm/mach-omap2/mmc-twl4030.h |1 +
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 736b039..a58deba 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -105,6 +105,14 @@ static int twl_mmc_get_ro(struct device *dev, int slot)
return gpio_get_value_cansleep(mmc->slots[0].gpio_wp);
}
+static int twl_mmc_get_cover_state(struct device *dev, int slot)
+{
+ struct omap_mmc_platform_data *mmc = dev->platform_data;
+
+ /* NOTE: assumes card detect signal is active-low */
+ return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
+}
+
/*
* MMC Slot Initialization.
*/
@@ -427,7 +435,10 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
mmc->slots[0].switch_pin = c->gpio_cd;
mmc->slots[0].card_detect_irq = gpio_to_irq(c->gpio_cd);
- mmc->slots[0].card_detect = twl_mmc_card_detect;
+ if (c->cover_only)
+ mmc->slots[0].get_cover_state =
twl_mmc_get_cover_state;
+ else
+ mmc->slots[0].card_detect = twl_mmc_card_detect;
} else
mmc->slots[0].switch_pin = -EINVAL;
diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
b/arch/arm/mach-omap2/mmc-twl4030.h
index 087a969..e87bc8d 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -12,6 +12,7 @@ struct twl4030_hsmmc_info {
booltransceiver;/* MMC-2 option */
boolext_clock; /* use external pin for input clock */
boolvsim_18v; /* MMC-2 option */
+ boolcover_only; /* No card detect - just cover switch */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
struct device *dev; /* returned: pointer to mmc adapter */
--
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
[PATCH 5/6] RX51: adjust hsmmc info
>From 6c1c8a4fa8b60ba777d878b7c4e2941826914a7c Mon Sep 17 00:00:00 2001
From: Adrian Hunter
Date: Fri, 23 Jan 2009 11:54:13 +0200
Subject: [PATCH] RX51: adjust hsmmc info
Signed-off-by: Adrian Hunter
---
arch/arm/mach-omap2/board-rx51-flash.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-flash.c
b/arch/arm/mach-omap2/board-rx51-flash.c
index 7af0d46..20fe242 100644
--- a/arch/arm/mach-omap2/board-rx51-flash.c
+++ b/arch/arm/mach-omap2/board-rx51-flash.c
@@ -52,16 +52,20 @@ static struct platform_device *rx51_flash_devices[] = {
static struct twl4030_hsmmc_info mmc[] __initdata = {
{
+ .name = "external",
.mmc= 1,
- .wires = 8,
+ .wires = 4,
+ .cover_only = true,
.gpio_cd= 160,
.gpio_wp= -EINVAL,
},
{
+ .name = "internal",
.mmc= 2,
.wires = 8,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .vsim_18v = true,
},
{} /* Terminator */
};
--
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
[PATCH 2/6] OMAP: mmc-twl4030 support VSIM is VMMC2_IO
>From 2f6a22e9091a09fb3cbb720356116035611636b2 Mon Sep 17 00:00:00 2001
From: Adrian Hunter
Date: Fri, 23 Jan 2009 11:45:49 +0200
Subject: [PATCH] OMAP: mmc-twl4030 support VSIM is VMMC2_IO
eMMC has two voltage lines, one for I/O and one for the
NAND core. This patch allows VSIM and VMMC2 respectively,
to be used for those two.
Signed-off-by: Adrian Hunter
---
arch/arm/mach-omap2/mmc-twl4030.c | 25 -
arch/arm/mach-omap2/mmc-twl4030.h |1 +
2 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index aeaab5a..736b039 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -52,6 +52,10 @@
#define VMMC_DEV_GRP_P10x20
+#define VSIM_DEV_GRP 0x37
+#define VSIM_18V 0x03
+#define VSIM_DEDICATED 0x3A
+
static u16 control_pbias_offset;
static u16 control_devconf1_offset;
@@ -61,6 +65,7 @@ static struct twl_mmc_controller {
struct omap_mmc_platform_data *mmc;
u8 twl_vmmc_dev_grp;
u8 twl_mmc_dedicated;
+ boolvsim_18v;
charname[HSMMC_NAME_LEN + 1];
} hsmmc[OMAP34XX_NR_MMC] = {
{
@@ -251,6 +256,19 @@ doit:
ret = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
vmmc, c->twl_mmc_dedicated);
+ if (ret)
+ return ret;
+
+ if (c->vsim_18v) {
+ u8 vsim = vmmc ? VSIM_18V : 0;
+
+ ret = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ dev_grp_val, VSIM_DEV_GRP);
+ if (ret)
+ return ret;
+ ret = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ vsim, VSIM_DEDICATED);
+ }
return ret;
}
@@ -437,7 +455,12 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
mmc->slots[0].set_power = twl_mmc2_set_power;
if (c->transceiver)
mmc->slots[0].ocr_mask = MMC2_OCR;
- else
+ else if (c->vsim_18v) {
+ mmc->slots[0].ocr_mask = MMC_VDD_27_28 |
+ MMC_VDD_28_29 | MMC_VDD_29_30 |
+ MMC_VDD_30_31 | MMC_VDD_31_32;
+ twl->vsim_18v = true;
+ } else
mmc->slots[0].ocr_mask = MMC_VDD_165_195;
break;
case 3:
diff --git a/arch/arm/mach-omap2/mmc-twl4030.h
b/arch/arm/mach-omap2/mmc-twl4030.h
index 21d3572..087a969 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -11,6 +11,7 @@ struct twl4030_hsmmc_info {
u8 wires; /* 1/4/8 wires */
booltransceiver;/* MMC-2 option */
boolext_clock; /* use external pin for input clock */
+ boolvsim_18v; /* MMC-2 option */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
struct device *dev; /* returned: pointer to mmc adapter */
--
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
[PATCH 0/6] mmc-twl4030 patches for RX51
Here are 6 patches for mmc-twl4030 for RX51. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Fix GPIO switch initial output state handling
The switchover to cross-platform GPIO interface unexpectedly caused all
output GPIO switches to be set to high state by default, unlike the
original OMAP code. Introduce a new GPIO switch flag to define the
initial state. Unless the flag is set, the default is now low state.
Also store the state of output switches directly into the switch struct
instead of trying to read an output GPIO.
Signed-off-by: Jani Nikula
---
arch/arm/plat-omap/gpio-switch.c | 13 +
arch/arm/plat-omap/include/mach/gpio-switch.h |1 +
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/gpio-switch.c b/arch/arm/plat-omap/gpio-switch.c
index 2b5665d..b278024 100644
--- a/arch/arm/plat-omap/gpio-switch.c
+++ b/arch/arm/plat-omap/gpio-switch.c
@@ -286,12 +286,17 @@ static int __init new_switch(struct gpio_switch *sw)
/* input: 1, output: 0 */
direction = !(sw->flags & OMAP_GPIO_SWITCH_FLAG_OUTPUT);
- if (direction)
+ if (direction) {
gpio_direction_input(sw->gpio);
- else
- gpio_direction_output(sw->gpio, true);
+ sw->state = gpio_sw_get_state(sw);
+ } else {
+ int state = sw->state =
+ !!(sw->flags & OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_HIGH);
- sw->state = gpio_sw_get_state(sw);
+ if (sw->flags & OMAP_GPIO_SWITCH_FLAG_INVERTED)
+ state = !state;
+ gpio_direction_output(sw->gpio, state);
+ }
r = 0;
r |= device_create_file(&sw->pdev.dev, &dev_attr_state);
diff --git a/arch/arm/plat-omap/include/mach/gpio-switch.h
b/arch/arm/plat-omap/include/mach/gpio-switch.h
index a143253..107d23f 100644
--- a/arch/arm/plat-omap/include/mach/gpio-switch.h
+++ b/arch/arm/plat-omap/include/mach/gpio-switch.h
@@ -29,6 +29,7 @@
#define OMAP_GPIO_SWITCH_TYPE_ACTIVITY 0x0002
#define OMAP_GPIO_SWITCH_FLAG_INVERTED 0x0001
#define OMAP_GPIO_SWITCH_FLAG_OUTPUT 0x0002
+#define OMAP_GPIO_SWITCH_FLAG_OUTPUT_INIT_HIGH 0x0004
struct omap_gpio_switch {
const char *name;
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5] LDP: Add support for built-in camera
On Mon, 2009-03-09 at 15:24 -0500, Aguirre Rodriguez, Sergio Alberto
wrote:
> Hi,
>
> > -Original Message-
> > From: stanley.miao [mailto:stanley.m...@windriver.com]
>
>
>
> > > +static struct i2c_board_info __initdata ldp_i2c_boardinfo_2[] = {
> > > +#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
> > > + {
> > > + I2C_BOARD_INFO("ov3640", OV3640_I2C_ADDR),
> > > + .platform_data = &ldp_ov3640_platform_data,
> > > + },
> > > +#endif
> > > +};
> > >
> > This new added i2c_board_info was not registered.
> > After I added this line,
> >
> > omap_register_i2c_bus(2, 400, ldp_i2c_boardinfo_2,
> > ARRAY_SIZE(ldp_i2c_boardinfo_2));
> >
> > the sensor was found. but the test still failed. A lot of error came out
> > when I run my test program.
> >
> > <3>CSI2: ComplexIO Error IRQ 80
> > CSI2: ComplexIO Error IRQ 80
> > <3>CSI2: ComplexIO Error IRQ c2
> > CSI2: ComplexIO Error IRQ c2
> > <3>CSI2: ComplexIO Error IRQ c2
> > CSI2: ComplexIO Error IRQ c2
> > <3>CSI2: ComplexIO Error IRQ c6
> > CSI2: ComplexIO Error IRQ c6
> > <3>CSI2: ECC correction failed
> > CSI2: ECC correction failed
> > <3>CSI2: ComplexIO Error IRQ 6
> > CSI2: ComplexIO Error IRQ 6
> > <3>CSI2: ComplexIO Error IRQ 6
> > CSI2: ComplexIO Error IRQ 6
> > <3>CSI2: ComplexIO Error IRQ 6
> > CSI2: ComplexIO Error IRQ 6
> > <3>CSI2: ComplexIO Error IRQ 6
> > CSI2: ComplexIO Error IRQ 6
> >
>
> Oops, my mistake. Missed to add that struct there... Fixed now.
>
> About the CSI2 errors you're receiving... Which version of LDP are you using?
> Which Silicon revision has (ES2.1 or ES3.0)?
ZOOM1 board(LDP3430-VG1.0.0-1), omap3430 ES2.1.
When I use your old version patch, sometimes the test succeed, sometimes
failed(no data was generated and no error). This version, always failed.
Thanks.
Stanley.
>
> Regards,
> Sergio
> >
> > Stanley.
--
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
[2.6.29-rc7][take #2][PATCH 0/3] ARM: OMAP: Add command line option for I2C bus speed
Hi These patches are for linux-omap but we want to wide discussion also to linux-i2c is the new command line option "i2c_bus=bus_id,clkrate" generic enough to be used for other architectures as well in the future. Patches are generated on top of mainline 2.6.29-rc7. Purpose of this command line option is to both allow to override the default board specific bus speed (patch 2) and register additional busses that are not registered from board initialization code (patch 3). Example for patch 2 would be the case where some on board component is upgraded and which allows to use e.g. higher clock rate on the bus without other major board changes. Patch 3 can have more practical use however. E.g. second I2C bus on TI BeagleBoard doesn't have on board components and thus it is not registered by default with omap_register_i2c_bus. This bus is routed to expansion pin header so with this patch it is able to register dynamically when needed. These patches are previously discussed in these threads: http://marc.info/?l=linux-omap&m=123635604511892&w=2 http://marc.info/?l=linux-omap&m=123661915517228&w=2 -- Jarkko -- 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
[2.6.29-rc7][take #2][PATCH 3/3] ARM: OMAP: Add method to register additional I2C busses on the command line
This patch extends command line option "i2c_bus=bus_id,clkrate" so that
it allow to register additional I2C busses that are not registered with
omap_register_i2c_bus from board initialization code.
Purpose of this is to register additional board busses which are routed
to external connectors only without any on board I2C devices.
Signed-off-by: Jarkko Nikula
---
Documentation/kernel-parameters.txt |2 +
arch/arm/plat-omap/i2c.c| 73 +--
2 files changed, 54 insertions(+), 21 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index d775076..ef9827f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -831,6 +831,8 @@ and is between 256 and 4096 characters. It is defined in
the file
terminal devices. Valid values: 0..8
i2c_bus=[HW] Override the default board specific I2C bus speed
+or register an additional I2C bus that is not
+registered from board initialization code.
Format:
,
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index aa70e43..a303071 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -98,6 +98,8 @@ static const int omap34xx_pins[][2] = {
static const int omap34xx_pins[][2] = {};
#endif
+#define OMAP_I2C_CMDLINE_SETUP (BIT(31))
+
static void __init omap_i2c_mux_pins(int bus)
{
int scl, sda;
@@ -133,6 +135,31 @@ static int __init omap_i2c_nr_ports(void)
return ports;
}
+static int __init omap_i2c_add_bus(int bus_id)
+{
+ struct platform_device *pdev;
+ struct resource *res;
+ resource_size_t base, irq;
+
+ pdev = &omap_i2c_devices[bus_id - 1];
+ if (bus_id == 1) {
+ res = pdev->resource;
+ if (cpu_class_is_omap1()) {
+ base = OMAP1_I2C_BASE;
+ irq = INT_I2C;
+ } else {
+ base = OMAP2_I2C_BASE1;
+ irq = INT_24XX_I2C1_IRQ;
+ }
+ res[0].start = base;
+ res[0].end = base + OMAP_I2C_SIZE;
+ res[1].start = irq;
+ }
+
+ omap_i2c_mux_pins(bus_id - 1);
+ return platform_device_register(pdev);
+}
+
/**
* omap_i2c_bus_setup - Process command line options for the I2C bus speed
* @str: String of options
@@ -154,11 +181,33 @@ static int __init omap_i2c_bus_setup(char *str)
if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
return 0;
i2c_rate[ints[1] - 1] = ints[2];
+ i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
return 1;
}
__setup("i2c_bus=", omap_i2c_bus_setup);
+/*
+ * Register busses defined in command line but that are not registered with
+ * omap_register_i2c_bus from board initialization code.
+ */
+static int __init omap_register_i2c_bus_cmdline(void)
+{
+ int i, err = 0;
+
+ for (i = 0; i < ARRAY_SIZE(i2c_rate); i++)
+ if (i2c_rate[i] & OMAP_I2C_CMDLINE_SETUP) {
+ i2c_rate[i] &= ~OMAP_I2C_CMDLINE_SETUP;
+ err = omap_i2c_add_bus(i + 1);
+ if (err)
+ goto out;
+ }
+
+out:
+ return err;
+}
+subsys_initcall(omap_register_i2c_bus_cmdline);
+
/**
* omap_register_i2c_bus - register I2C bus with device descriptors
* @bus_id: bus id counting from number 1
@@ -173,9 +222,6 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
unsigned len)
{
int err;
- struct platform_device *pdev;
- struct resource *res;
- resource_size_t base, irq;
BUG_ON(bus_id < 1 || bus_id > omap_i2c_nr_ports());
@@ -185,24 +231,9 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
return err;
}
- pdev = &omap_i2c_devices[bus_id - 1];
- if (i2c_rate[bus_id - 1] == 0)
+ if (!i2c_rate[bus_id - 1])
i2c_rate[bus_id - 1] = clkrate;
+ i2c_rate[bus_id - 1] &= ~OMAP_I2C_CMDLINE_SETUP;
- if (bus_id == 1) {
- res = pdev->resource;
- if (cpu_class_is_omap1()) {
- base = OMAP1_I2C_BASE;
- irq = INT_I2C;
- } else {
- base = OMAP2_I2C_BASE1;
- irq = INT_24XX_I2C1_IRQ;
- }
- res[0].start = base;
- res[0].end = base + OMAP_I2C_SIZE;
- res[1].start = irq;
- }
-
- omap_i2c_mux_pins(bus_id - 1);
- return platform_device_register(pdev);
+ return omap_i2c_add_bus(bus_id);
}
--
1.6.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord
[2.6.29-rc7][take #2][PATCH 2/3] ARM: OMAP: Add command line option for I2C bus speed
This patch adds a new command line option "i2c_bus=bus_id,clkrate" into
I2C bus registration helper. Purpose of the option is to override the
default board specific bus speed which is supplied by the
omap_register_i2c_bus.
The default bus speed is typically set to speed of slowest I2C chip on the
bus and overriding allow to use some experimental configurations or updated
chip versions without any kernel modifications.
Signed-off-by: Jarkko Nikula
---
Documentation/kernel-parameters.txt |4 ++
arch/arm/plat-omap/i2c.c| 54 --
2 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 54f21a5..d775076 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -830,6 +830,10 @@ and is between 256 and 4096 characters. It is defined in
the file
hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
terminal devices. Valid values: 0..8
+ i2c_bus=[HW] Override the default board specific I2C bus speed
+Format:
+,
+
i8042.debug [HW] Toggle i8042 debug mode
i8042.direct[HW] Put keyboard port into non-translated mode
i8042.dumbkbd [HW] Pretend that controller can only read data from
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 3e95954..aa70e43 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -119,6 +119,46 @@ static void __init omap_i2c_mux_pins(int bus)
omap_cfg_reg(scl);
}
+static int __init omap_i2c_nr_ports(void)
+{
+ int ports = 0;
+
+ if (cpu_class_is_omap1())
+ ports = 1;
+ else if (cpu_is_omap24xx())
+ ports = 2;
+ else if (cpu_is_omap34xx())
+ ports = 3;
+
+ return ports;
+}
+
+/**
+ * omap_i2c_bus_setup - Process command line options for the I2C bus speed
+ * @str: String of options
+ *
+ * This function allow to override the default I2C bus speed for given I2C
+ * bus with a command line option.
+ *
+ * Format: i2c_bus=bus_id,clkrate (in kHz)
+ *
+ * Returns 1 on success, 0 otherwise.
+ */
+static int __init omap_i2c_bus_setup(char *str)
+{
+ int ports;
+ int ints[3];
+
+ ports = omap_i2c_nr_ports();
+ get_options(str, 3, ints);
+ if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
+ return 0;
+ i2c_rate[ints[1] - 1] = ints[2];
+
+ return 1;
+}
+__setup("i2c_bus=", omap_i2c_bus_setup);
+
/**
* omap_register_i2c_bus - register I2C bus with device descriptors
* @bus_id: bus id counting from number 1
@@ -132,19 +172,12 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
struct i2c_board_info const *info,
unsigned len)
{
- int ports, err;
+ int err;
struct platform_device *pdev;
struct resource *res;
resource_size_t base, irq;
- if (cpu_class_is_omap1())
- ports = 1;
- else if (cpu_is_omap24xx())
- ports = 2;
- else if (cpu_is_omap34xx())
- ports = 3;
-
- BUG_ON(bus_id < 1 || bus_id > ports);
+ BUG_ON(bus_id < 1 || bus_id > omap_i2c_nr_ports());
if (info) {
err = i2c_register_board_info(bus_id, info, len);
@@ -153,7 +186,8 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
}
pdev = &omap_i2c_devices[bus_id - 1];
- *(u32 *)pdev->dev.platform_data = clkrate;
+ if (i2c_rate[bus_id - 1] == 0)
+ i2c_rate[bus_id - 1] = clkrate;
if (bus_id == 1) {
res = pdev->resource;
--
1.6.1.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
[2.6.29-rc7][take #2][PATCH 1/3] ARM: OMAP: Add documentation for function omap_register_i2c_bus
Signed-off-by: Jarkko Nikula --- arch/arm/plat-omap/i2c.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c index 467531e..3e95954 100644 --- a/arch/arm/plat-omap/i2c.c +++ b/arch/arm/plat-omap/i2c.c @@ -119,6 +119,15 @@ static void __init omap_i2c_mux_pins(int bus) omap_cfg_reg(scl); } +/** + * omap_register_i2c_bus - register I2C bus with device descriptors + * @bus_id: bus id counting from number 1 + * @clkrate: clock rate of the bus in kHz + * @info: pointer into I2C device descriptor table or NULL + * @len: number of descriptors in the table + * + * Returns 0 on success or an error code. + */ int __init omap_register_i2c_bus(int bus_id, u32 clkrate, struct i2c_board_info const *info, unsigned len) -- 1.6.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] OV3640: Add driver
> -Original Message- > From: Tuukka.O Toivonen [mailto:tuukka.o.toivo...@nokia.com] > Sent: Tuesday, March 10, 2009 9:30 AM > To: Menon, Nishanth > Cc: Aguirre Rodriguez, Sergio Alberto; Alexey Klimov; linux- > me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus; Doyu > Hiroshi (Nokia-D/Helsinki); DongSoo(Nathaniel) Kim; MiaoStanley; Nagalla, > Hari; Hiremath, Vaibhav; Lakhani, Amish > Subject: Re: [PATCH 3/5] OV3640: Add driver > > On Monday 09 March 2009 23:29:27 ext Menon, Nishanth wrote: > > Further, we have multiple sensors following CCI[1] - why not have a > driver > > for the same, it will simplify the entire process - ov3640, mt9p012 both > > follow the spec at least.. dependency would be sensor -> cci dev->i2c > > framework. > > Sakari has written smiaregs.c pretty much exactly for this > purpose. You should check it out. Yes, smiaregs probably has a few more functionality than pure reg access APIs. Comparing CCI as defined in CCP2 spec and CSI2 spec, CCP2 spec says - register addressing could be 8 or 16, but the data size is 8 bit. In the case of CSI2, the data size could be 8, 16, 32 or 64 bytes.. we could say that CSI2's CCI is kind of a superset of CCI as defined by CCP2 spec. Might be a good idea to split the cci access out of smia_regs.c and make it a little more generic so that devices not caring for smia register set organization but using MIPI type access could also use it. Regards, Nishanth Menon Ref: [1] MIPI CSI2 revision 1.0 [2] SMIA CCP2 spec rev 1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] OV3640: Add driver
On Monday 09 March 2009 23:29:27 ext Menon, Nishanth wrote: > Further, we have multiple sensors following CCI[1] - why not have a driver > for the same, it will simplify the entire process - ov3640, mt9p012 both > follow the spec at least.. dependency would be sensor -> cci dev->i2c > framework. Sakari has written smiaregs.c pretty much exactly for this purpose. You should check it out. - Tuukka -- 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
