RE: [PATCH] omap4: mmc: Fix the regulator resource for MMC2
ping
-Original Message-
From: Shilimkar, Santosh
Sent: Thursday, June 10, 2010 9:05 PM
To: Shilimkar, Santosh; linux-omap@vger.kernel.org
Cc: Nayak, Rajendra; Ghorai, Sukumar; Kadiyala, Kishore
Subject: RE: [PATCH] omap4: mmc: Fix the regulator resource for MMC2
Tony,
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, May 28, 2010 9:38 PM
To: linux-omap@vger.kernel.org
Cc: Shilimkar, Santosh; Nayak, Rajendra; Ghorai, Sukumar; Kadiyala,
Kishore
Subject: [PATCH] omap4: mmc: Fix the regulator resource for MMC2
The MMC1 and MMC2 cards have seperate LDO supplies. Current code assumes
that they are powered by same LDO.
This patch fixes the same and has VAUX1 as supply to MMC2 card.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Tested-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Tested with omap3_defconfig on OMAP4430SDP
Any comments on this one ??
arch/arm/mach-omap2/board-4430sdp.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index 7a78986..f62042e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -384,14 +384,16 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
+static struct regulator_consumer_supply sdp4430_vaux_supply[] = {
{
.supply = vmmc,
- .dev_name = mmci-omap-hs.0,
+ .dev_name = mmci-omap-hs.1,
},
+};
+static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
{
.supply = vmmc,
- .dev_name = mmci-omap-hs.1,
+ .dev_name = mmci-omap-hs.0,
},
};
@@ -447,6 +449,8 @@ static struct regulator_init_data sdp4430_vaux1 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = sdp4430_vaux_supply,
};
static struct regulator_init_data sdp4430_vaux2 = {
@@ -487,7 +491,7 @@ static struct regulator_init_data sdp4430_vmmc = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 2,
+ .num_consumer_supplies = 1,
.consumer_supplies = sdp4430_vmmc_supply,
};
--
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 v3 1/8] omap3 flash: rename board-sdp-flash.c to be use by other boards
Sukumar, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Monday, July 05, 2010 5:53 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH v3 1/8] omap3 flash: rename board-sdp-flash.c to be use by other boards * Sukumar Ghorai s-gho...@ti.com [100616 14:34]: rename board-sdp-flash.c(board-flash.c) and board-sdp.h(board-flash.h) to used by other board e.g. zoom Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/board-3430sdp.c| 16 ++- arch/arm/mach-omap2/board-flash.c | 253 ++ arch/arm/mach-omap2/board-sdp-flash.c | 267 - --- arch/arm/mach-omap2/include/mach/board-flash.h | 28 +++ arch/arm/mach-omap2/include/mach/board-sdp.h | 21 -- 6 files changed, 296 insertions(+), 291 deletions(-) create mode 100755 arch/arm/mach-omap2/board-flash.c delete mode 100755 arch/arm/mach-omap2/board-sdp-flash.c create mode 100644 arch/arm/mach-omap2/include/mach/board-flash.h delete mode 100644 arch/arm/mach-omap2/include/mach/board-sdp.h Looks like this one won't apply: patching file arch/arm/mach-omap2/board-sdp-flash.c Hunk #1 FAILED at 1. File arch/arm/mach-omap2/board-sdp-flash.c is not empty after patch, as expected Try git format-patch -M when creating renaming patch. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC
-Original Message-
From: Grazvydas Ignotas [mailto:nota...@gmail.com]
Sent: Saturday, July 03, 2010 2:25 AM
To: linux-fb...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; Tomi Valkeinen; Hiremath, Vaibhav; Grazvydas
Ignotas
Subject: [PATCH] OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC
FBIO_WAITFORVSYNC is a stardard ioctl for waiting vsync, already
used by some userspace, so add it as an alias for OMAPFB_WAITFORVSYNC.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
Tomi,
I know I already sent this earlier, but as now FBIO_WAITFORVSYNC is a
standard ioctl, so why don't we support it? I know you might not like
that omapfb_ioctl will have one standard ioctl handler between all OMAP
specific ones, but that's something plenty of other drivers do.
[Hiremath, Vaibhav] We should always use standard interfaces wherever possible
and I think Tomi will also be aligned on this.
drivers/video/omap2/omapfb/omapfb-ioctl.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 9c73618..32fab5a 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -490,6 +490,7 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
struct omapfb_vram_info vram_info;
struct omapfb_tearsync_info tearsync_info;
struct omapfb_display_info display_info;
+ u32 crt;
} p;
int r = 0;
@@ -648,6 +649,17 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
r = -EFAULT;
break;
+ case FBIO_WAITFORVSYNC:
+ if (get_user(p.crt, (__u32 __user *)arg)) {
+ r = -EFAULT;
+ break;
+ }
+ if (p.crt != 0) {
+ r = -ENODEV;
+ break;
+ }
+ /* FALLTHROUGH */
+
case OMAPFB_WAITFORVSYNC:
[Hiremath, Vaibhav] I don't see any reason why we should still keep old custom
IOCTL support here.
Thanks,
Vaibhav
DBG(ioctl WAITFORVSYNC\n);
if (!display) {
--
1.6.3.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 v3 1/8] omap3 flash: rename board-sdp-flash.c to be use by other boards
Tony, -Original Message- From: Shilimkar, Santosh Sent: Tuesday, July 06, 2010 11:35 AM To: Tony Lindgren; Ghorai, Sukumar Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH v3 1/8] omap3 flash: rename board-sdp-flash.c to be use by other boards Sukumar, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Monday, July 05, 2010 5:53 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH v3 1/8] omap3 flash: rename board-sdp-flash.c to be use by other boards * Sukumar Ghorai s-gho...@ti.com [100616 14:34]: rename board-sdp-flash.c(board-flash.c) and board-sdp.h(board-flash.h) to used by other board e.g. zoom Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/board-3430sdp.c| 16 ++- arch/arm/mach-omap2/board-flash.c | 253 ++ arch/arm/mach-omap2/board-sdp-flash.c | 267 --- -- --- arch/arm/mach-omap2/include/mach/board-flash.h | 28 +++ arch/arm/mach-omap2/include/mach/board-sdp.h | 21 -- 6 files changed, 296 insertions(+), 291 deletions(-) create mode 100755 arch/arm/mach-omap2/board-flash.c delete mode 100755 arch/arm/mach-omap2/board-sdp-flash.c create mode 100644 arch/arm/mach-omap2/include/mach/board-flash.h delete mode 100644 arch/arm/mach-omap2/include/mach/board-sdp.h Looks like this one won't apply: patching file arch/arm/mach-omap2/board-sdp-flash.c Hunk #1 FAILED at 1. File arch/arm/mach-omap2/board-sdp-flash.c is not empty after patch, as expected Try git format-patch -M when creating renaming patch. [Ghorai] Thanks Tony Santosh.. And I think I understood the problem of my format-patch option. Please check with the attached patch(updated). Regards, Ghorai 0001-omap3-flash-rename-board-sdp-flash.c-to-be-use-by-o.patch Description: 0001-omap3-flash-rename-board-sdp-flash.c-to-be-use-by-o.patch
Re: [PATCH 02/15] wireless: wl1271: remove SDIO IDs from driver
On Tue, 2010-07-06 at 02:37 +0200, ext Ohad Ben-Cohen wrote: From: Ohad Ben-Cohen oh...@ti.com Remove SDIO IDs from the driver code since now it is included in linux/mmc/sdio_ids.h. Signed-off-by: Ohad Ben-Cohen oh...@ti.com --- Acked-by: Luciano Coelho luciano.coe...@nokia.com -- Cheers, Luca. -- 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 10/15] wireless: wl1271: support return value for the set power func
On Tue, 2010-07-06 at 02:37 +0200, ext Ohad Ben-Cohen wrote: From: Ohad Ben-Cohen oh...@ti.com Make it possible for the set power method to indicate a success/failure return value. This is needed to support more complex power on/off operations such as bringing up (and down) sdio functions. Signed-off-by: Ohad Ben-Cohen oh...@ti.com --- Acked-by: Luciano Coelho luciano.coe...@nokia.com -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/15] wireless: wl1271: make wl12xx.h common to both spi and sdio
On Tue, 2010-07-06 at 02:37 +0200, ext Ohad Ben-Cohen wrote: From: Ohad Ben-Cohen oh...@ti.com Move wl12xx.h outside of the spi-specific location, so it can be shared with both spi and sdio solutions. Signed-off-by: Ohad Ben-Cohen oh...@ti.com --- drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +- drivers/net/wireless/wl12xx/wl1251_spi.c |2 +- drivers/net/wireless/wl12xx/wl1271_spi.c |2 +- include/linux/spi/wl12xx.h| 34 - include/linux/wl12xx.h| 34 + 5 files changed, 37 insertions(+), 37 deletions(-) delete mode 100644 include/linux/spi/wl12xx.h create mode 100644 include/linux/wl12xx.h For the wl1271 part: Acked-by: Luciano Coelho luciano.coe...@nokia.com For the wl12xx.h and wl1251 parts, this needs to be acked by Kalle Valo. -- Cheers, Luca. -- 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 resend 1/3] AM35x: Add musb support
Hi, If a Kconfig option is needed for optionally compiling in the support for am35x musb, it should be called USB_MUSB_AM35X or similar that gets selected if the boards using it are selected. Do you mean that we should have this option in drivers/usb/musb/Kconfig? Yeah, it could be set automatically with default y if MACH_AM35X_SOME_BOARD. Then options like this should not be mutually exclusive like they currently are for musb, that breaks using musb with multi omap. Choosing USB_MUSB_AM35X would anyways compile am35x.c and not omap2430.c File; thus musb would not work on OMAP3x boards with same binary. You should set up things so both can be compiled in, that's standard behaviour for all Linux drivers :) This is much easier said than done. Tony, As musb controllers are quite different between OMAPs and AM35x so it would be difficult in terms of software maintenance with such approach. Some of the major changes in AM35x are, - Has builtin USB PHY - It doesn't use Mentor DMA but uses CPPI4.1 DMA - Has set of wrapper register which are not present on OMAPs. - Doesn't have SYSCONFIG registers which are present on OMAPs. - Has bytewise read limitation which is not applicable to OMAPs. Musb on AM35x is actually quite similar to musb on DA8xx family of Devices. I can update the patches to use USB_MUSB_AM35X config within drivers/usb/musb/ but that would still not be able to compile in Both omapx and am35x stuff in single binary. Thanks, Ajay I will update the patches and submit for further reviews. Thanks, Tony WBR, Sergei -- 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 resend 1/3] AM35x: Add musb support
* Gupta, Ajay Kumar ajay.gu...@ti.com [100706 10:17]: As musb controllers are quite different between OMAPs and AM35x so it would be difficult in terms of software maintenance with such approach. Hmm, this is all pretty standard stuff.. Some of the major changes in AM35x are, - Has builtin USB PHY Register the PHY from platform data. - It doesn't use Mentor DMA but uses CPPI4.1 DMA Register DMA functions from platform data. - Has set of wrapper register which are not present on OMAPs. Yeah tusb6010 has the same problem, but that's already dealt with I believe. - Doesn't have SYSCONFIG registers which are present on OMAPs. - Has bytewise read limitation which is not applicable to OMAPs. Sounds like this has been mostly dealt with already with tusb6010. Musb on AM35x is actually quite similar to musb on DA8xx family of Devices. I can update the patches to use USB_MUSB_AM35X config within drivers/usb/musb/ but that would still not be able to compile in Both omapx and am35x stuff in single binary. Sounds like we should first fix thing before adding new code that will make fixing the basic issues harder. 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: [PATCHv3 4/4] [OMAP] HTCHERALD: MMC, I2C, HTCPLD and related devices
* Cory Maccarrone darkstar6...@gmail.com [100601 18:49]: This change adds in MMC and I2C support to the HTC Herald board, as well as adding the HTCPLD driver for the PLD used on this phone. It also adds in the gpio-keys entries for the front directional keys and selector and the cursor keys on the slide-out keyboard, and gpio-leds support for the LEDs attached to the htcpld. The Kconfig was also modified to add 64 GPIOs and IRQs to the default maximum number of each for the HTC herald. This is needed because the HTCPLD chip on this board exposes an additional 32 gpios and 16 irqs that would not fit in the default limits. The defconfig has been updated to reflect the changes. This one needs to be updated too to leave out the defconfig changes. Thanks, 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 resend 1/3] AM35x: Add musb support
Hi,
On Tue, Jul 06, 2010 at 09:57:09AM +0200, ext Tony Lindgren wrote:
Sounds like we should first fix thing before adding new code
that will make fixing the basic issues harder.
my idea to deal with this is to have a set of platform glue drivers.
So omap2430.c, blackfin.c, tusb6010 and davinci.c would become a
platform driver themselves that would instantiate musb-hdrc
platform_driver and the correct dma driver (inventra, omap, cppi, etc).
It would look something like:
#include plat/usb.h
static struct musb_hdrc_ops omap2430_musb_ops = {
.readb = generic_readb,
.readw = generic_readw,
.readl = generic_readl,
.writeb = generic_writeb,
.writew = generic_writew,
.writel = generic_writel,
};
static struct musb_platform_data omap2430_musb_data = {
.ops= omap2430_musb_ops,
.mode = -EINVAL, /* change it later */
};
static int __init omap2430_musb_probe(struct platform_device *pdev)
{
struct omap24030_musb_platform_data pdata = pdev-dev.platform_data;
musb = platform_device_alloc(musb-hdrc, -1);
/* check error */
musb-dev.parent = pdev-dev;
omap2430_musb_data.mode = pdata-mode;
/* initialize every other necessary field */
platform_device_add_data(musb, omap2430_musb_data);
dma = platform_device_alloc(dma-inventra, -1);
/* check error */
dma-dev.parent = pdev-dev;
/* add both devices */
return 0;
}
static int omap2430_musb_suspend(struct platform_device *pdev,
pm_message_t state)
{
return omap2430_musb_save_context(pdev);
}
static int omap2430_musb_resume(stuct platform_device *pdev)
{
omap2430_musb_restore_context(pdev);
}
this would allow us to factor-out save/restore context, get rid of all
exported functions (by just adding every necessary function to
musb_hdrc_ops) and compile in every single musb file in one driver and
still have it working. Boards would, then, just instantiate
musb-omap2430/musb-blackfin/musb-tusb6010/musb-davinci
platform_driver(s) and the rest would be done on runtime, since only the
driver that matches would actually probe.
How does that sound ??
--
balbi
DefectiveByDesign.org
--
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 11/15] wireless: wl1271: introduce platform device support
Hi, On 07/06/2010 03:37 AM, ext Ohad Ben-Cohen wrote: From: Ohad Ben-Cohenoh...@ti.com Introduce a platform device support which is decoupled from the life cycle of the sdio function. The platform device objective is to deliver board-specific values (like irq, ref_clock, and software card-detect emulation control). The driver can then dynamically create (or destroy) the sdio function whenever the wlan interface is brought up (or down), as part of the power() operation. Is this the right approach? Why should you emulate a card disconnect event when the wlan interface is brought down? Physically the card is never disconnected. So I don't see why we should fake it. Could you please explain why you need to do this? br, -roger -- 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] omap4: mmc: Fix the regulator resource for MMC2
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: devel-boards Initial commit ID (Likely to change): 4b78f83d08ecac0c9b7aa1ee72345be4657abcb9 PatchWorks http://patchwork.kernel.org/patch/102918/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=4b78f83d08ecac0c9b7aa1ee72345be4657abcb9 -- 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/8] musb: fix compilation warning in host only mode
On Thu, Jun 24, 2010 at 03:10:01PM +0200, ext Sergei Shtylyov wrote:
@@ -714,12 +713,16 @@ static irqreturn_t musb_stage0_irq(struct musb
#ifdef CONFIG_USB_MUSB_OTG
/* flush endpoints when transitioning from Device Mode */
- if (is_peripheral_active(musb)) {
- /* REVISIT HNP; just force disconnect */
- }
- musb_writew(mbase, MUSB_INTRTXE, musb-epmask);
- musb_writew(mbase, MUSB_INTRRXE, musb-epmask 0xfffe);
- musb_writeb(mbase, MUSB_INTRUSBE, 0xf7);
+ {
and adding unneded identation level ?? no thanks. Dereferencing musb to
access mbase sounds better to me.
--
balbi
DefectiveByDesign.org
--
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/8] musb: fix compilation warning in host only mode
Hi,
On Thu, Jun 24, 2010 at 01:17:54PM +0200, ext Gupta, Ajay Kumar wrote:
Fixes below compilation warning when host only configuration is
selected.
drivers/usb/musb/musb_core.c: In function 'musb_stage0_irq':
drivers/usb/musb/musb_core.c:711: warning: unused variable 'mbase'
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Acked-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/usb/musb/musb_core.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index a8b0440..ed6e1a4 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -704,7 +704,6 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
#ifdef CONFIG_USB_MUSB_HDRC_HCD
if (int_usb MUSB_INTR_CONNECT) {
struct usb_hcd *hcd = musb_to_hcd(musb);
- void __iomem *mbase = musb-mregs;
handled = IRQ_HANDLED;
musb-is_active = 1;
@@ -717,9 +716,9 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
if (is_peripheral_active(musb)) {
/* REVISIT HNP; just force disconnect */
}
- musb_writew(mbase, MUSB_INTRTXE, musb-epmask);
- musb_writew(mbase, MUSB_INTRRXE, musb-epmask 0xfffe);
- musb_writeb(mbase, MUSB_INTRUSBE, 0xf7);
+ musb_writew(musb-mregs, MUSB_INTRTXE, musb-epmask);
+ musb_writew(musb-mregs, MUSB_INTRRXE, musb-epmask 0xfffe);
+ musb_writeb(musb-mregs, MUSB_INTRUSBE, 0xf7);
#endif
musb-port1_status = ~(USB_PORT_STAT_LOW_SPEED
|USB_PORT_STAT_HIGH_SPEED
--
balbi
DefectiveByDesign.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH[V2 1/3]: Update Platform files for SPI
On Thu, Feb 18, 2010 at 11:29 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Thu, Feb 18, 2010 at 10:09 AM, Tony Lindgren t...@atomide.com wrote: * Grant Likely grant.lik...@secretlab.ca [100218 08:26]: On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote: * Hemanth V heman...@ti.com [100203 02:19]: From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 27 Nov 2009 14:22:30 +0530 Subject: [PATCH] Update platform files This patch updates platform files for fifo, slave support Signed-off-by: Hemanth V heman...@ti.com This should get merged via the spi-devel list with the other patches. Acked-by: Tony Lindgren t...@atomide.com Tony, do you want me to add your acked-by to patches 2 3? No thanks, I've only looked at them briefly. Okay, thanks. Hemanth, I'm going to drop this series for the moment. I'd like to see some feedback/acks from current users and maintainers of the omap2_mcspi driver before I merge support, especially now when the merge window is about to open and it hasn't gotten any linux-next exposure. Also, what is your feeling about patch 3/3, spi slave support. spi slave usage model is still a matter under debate, but that patch doesn't touch core spi code, so I'm okay to merge it as a driver-specific feature. However, I'm not convinced that it is actually a useful patch to merge yet, so I'll defer to you on this one. Thoughts? Up to you to decide. But here's my experience so far.. Based on my experience if temporary hacks are merged, then nobody bothers to clean them up properly afterwards and the clean-up task unfairly falls on the maintainer. So IMHO, hacks like that are better floating on the mailing list until they're properly done. It's best to concentrate on getting the core things done right to make long term support easier. Right, I agree. I'll ignore patch 3 entirely until I at least see a patch for an in-tree user. Hi Hemanth. Could you please respin patches 1 and 2 against 2.6.35-rc3? The current patches do not apply anymore. Grant, Govindraj marked in this mail would rebase the patches and post the same. Thanks Hemanth -- 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 11/15] wireless: wl1271: introduce platform device support
Hi Roger, On Tue, Jul 6, 2010 at 11:53 AM, Roger Quadros roger.quad...@nokia.com wrote: Could you please explain why you need to do this? To minimize power consumption when the wlan device is not in use, we would like to keep the device powered off as long as the interface is down, and only power it on when the user brings up the interface. Whenever the chip is powered on, it must be initialized and reconfigured by mmc_attach_sdio, and the wl1271 driver have to wait for that phase to successfully complete (essentially waiting for the sdio_driver's probe function to be called). To make sure this SDIO init step occurs correctly every time we toggle the device's power back on, and to prevent potential races, we also have to make sure that the sdio function is removed every time we power off the chip (the driver waits for the sdio_driver's remove function to be called). That's why we let the mmc layer think that the card is removed: physically it is still there, but for all practical purposes it is really removed, because once you power off the chip, you must reinitialize it again next time you power it on, as if the card was really removed and re-inserted. Thanks, Ohad. br, -roger -- 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 resend 1/3] AM35x: Add musb support
* Felipe Balbi felipe.ba...@nokia.com [100706 11:40]:
Hi,
On Tue, Jul 06, 2010 at 09:57:09AM +0200, ext Tony Lindgren wrote:
Sounds like we should first fix thing before adding new code
that will make fixing the basic issues harder.
my idea to deal with this is to have a set of platform glue
drivers. So omap2430.c, blackfin.c, tusb6010 and davinci.c would
become a platform driver themselves that would instantiate musb-hdrc
platform_driver and the correct dma driver (inventra, omap, cppi,
etc).
It would look something like:
#include plat/usb.h
static struct musb_hdrc_ops omap2430_musb_ops = {
.readb = generic_readb,
.readw = generic_readw,
.readl = generic_readl,
.writeb = generic_writeb,
.writew = generic_writew,
.writel = generic_writel,
};
static struct musb_platform_data omap2430_musb_data = {
.ops= omap2430_musb_ops,
.mode = -EINVAL, /* change it later */
};
static int __init omap2430_musb_probe(struct platform_device *pdev)
{
struct omap24030_musb_platform_data pdata = pdev-dev.platform_data;
musb = platform_device_alloc(musb-hdrc, -1);
/* check error */
musb-dev.parent = pdev-dev;
omap2430_musb_data.mode = pdata-mode;
/* initialize every other necessary field */
platform_device_add_data(musb, omap2430_musb_data);
dma = platform_device_alloc(dma-inventra, -1);
/* check error */
dma-dev.parent = pdev-dev;
/* add both devices */
return 0;
}
static int omap2430_musb_suspend(struct platform_device *pdev,
pm_message_t state)
{
return omap2430_musb_save_context(pdev);
}
static int omap2430_musb_resume(stuct platform_device *pdev)
{
omap2430_musb_restore_context(pdev);
}
this would allow us to factor-out save/restore context, get rid of
all exported functions (by just adding every necessary function to
musb_hdrc_ops) and compile in every single musb file in one driver
and still have it working. Boards would, then, just instantiate
musb-omap2430/musb-blackfin/musb-tusb6010/musb-davinci
platform_driver(s) and the rest would be done on runtime, since only
the driver that matches would actually probe.
How does that sound ??
That sounds good to me! It would be nice to have usable musb with
soon-to-be-gone omap3_defconfig :)
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] OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC
On Tue, Jul 06, 2010 at 08:08:14AM +0200, ext Hiremath, Vaibhav wrote:
@@ -648,6 +649,17 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
r = -EFAULT;
break;
+ case FBIO_WAITFORVSYNC:
+ if (get_user(p.crt, (__u32 __user *)arg)) {
+ r = -EFAULT;
+ break;
+ }
+ if (p.crt != 0) {
+ r = -ENODEV;
+ break;
+ }
+ /* FALLTHROUGH */
+
case OMAPFB_WAITFORVSYNC:
[Hiremath, Vaibhav] I don't see any reason why we should still keep old
custom IOCTL support here.
It can already be used so it should not be removed.
--
Ville Syrjälä
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
Hi Nicolas, On Tue, Jul 6, 2010 at 4:45 AM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 6 Jul 2010, Ohad Ben-Cohen wrote: From: Ohad Ben-Cohen oh...@ti.com Add support for software emulation of card detect events. This is required for specific controllers that are hard wired with embedded SDIO devices (such as TI's wl1271 WLAN device). Why? Many instances of hardwired SDIO based WLAN devices do exist already, and they don't need extra card detect events to be generated. The core MMC code already triggers a probe for cards whenever a new host controller is registered. We prefer not to power up the chip as early as boot time; instead, we would like to have it powered off until the wlan interface is brought up, power it on when the interface is brought up, and power it off again as soon as the interface is brought down again (to minimize power consumption when the wlan is not in use). For that we can't rely on the probing done when the controller is registered, we want to have a mechanism to allow dynamic detection and removal of the card. Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better. Board-specific configuration is required to enable this software card detect control. Could you elaborate please? Please check out the last patch - that patch is doing that configuration. In essence, this virtual card detect mechanism is enabled only for specific controllers which we know there's an embedded sdio device hardwired to. This knowledge is board-specific, and that's why we enable this mechanism in the board files, per a specific mmc controller. Thanks, Ohad. Nicolas -- 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 11/15] wireless: wl1271: introduce platform device support
Hi Ohad, On 07/06/2010 12:30 PM, ext Ohad Ben-Cohen wrote: Hi Roger, On Tue, Jul 6, 2010 at 11:53 AM, Roger Quadrosroger.quad...@nokia.com wrote: Could you please explain why you need to do this? To minimize power consumption when the wlan device is not in use, we would like to keep the device powered off as long as the interface is down, and only power it on when the user brings up the interface. Agreed. Whenever the chip is powered on, it must be initialized and reconfigured by mmc_attach_sdio, and the wl1271 driver have to wait for that phase to successfully complete (essentially waiting for the sdio_driver's probe function to be called). To make sure this SDIO init step occurs correctly every time we toggle the device's power back on, and to prevent potential races, we also have to make sure that the sdio function is removed every time we power off the chip (the driver waits for the sdio_driver's remove function to be called). That's why we let the mmc layer think that the card is removed: physically it is still there, but for all practical purposes it is really removed, because once you power off the chip, you must reinitialize it again next time you power it on, as if the card was really removed and re-inserted. My point is that shouldn't this be handled by SDIO core? If there are no users for the SDIO function and the card, doesn't the SDIO core power down the slot, and take care of re-initialization when it is powered up? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
On 07/06/2010 01:22 PM, ext Ohad Ben-Cohen wrote: Hi Nicolas, On Tue, Jul 6, 2010 at 4:45 AM, Nicolas Pitren...@fluxnic.net wrote: On Tue, 6 Jul 2010, Ohad Ben-Cohen wrote: From: Ohad Ben-Cohenoh...@ti.com Add support for software emulation of card detect events. This is required for specific controllers that are hard wired with embedded SDIO devices (such as TI's wl1271 WLAN device). Why? Many instances of hardwired SDIO based WLAN devices do exist already, and they don't need extra card detect events to be generated. The core MMC code already triggers a probe for cards whenever a new host controller is registered. We prefer not to power up the chip as early as boot time; instead, we Why? if the card is hard wired with no card detect then it should be powered up. The function driver should power it down later if required. no? would like to have it powered off until the wlan interface is brought up, power it on when the interface is brought up, If it was powered OFF then how did the wlan interface come into picture? and power it off again as soon as the interface is brought down again (to minimize power consumption when the wlan is not in use). I agree, we some how need to power down the card when not in use in the right way. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP: clock, hwmod, omap_device, PM constraints: patches for 2.6.36
* Paul Walmsley p...@pwsan.com [100704 00:43]:
Hi Tony,
here's the pull request for some clock, hwmod, omap_device, PM constraints
patches for 2.6.36.
Thanks, pulled into omap-for-linus.
Tony
- Paul
The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02:
Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 for_2.6.36
Anand Gadiyar (1):
OMAP3: wait on IDLEST after enabling USBTLL fclk
Benoit Cousson (1):
OMAP23: hwmod: Remove _hwmod prefix in name string
Kevin Hilman (8):
OMAP24xx: CM: fix mask used for checking IDLEST status
OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLEST
OMAP: hwmod: add non-locking versions of enable and idle functions
OMAP: omap_device: ensure hwmod tracks attached omap_device pointer
OMAP: PM: create omap_devices for MPU, DSP, L3
OMAP: hwmod data: add class for IVA hwmods
OMAP23: hwmod: Replace l3 - l3_main
OMAP3: hwmod data: add data for OMAP3 IVA2
Paul Walmsley (9):
OMAP: clock: add kerneldoc for structures; move flags closer to structs
OMAP1: OPP: add KConfig entry for 96MHz ARM rate (using a 12MHz
oscillator)
OMAP1: clock: some cleanup
OMAP: hwmod: allow omap_hwmod_late_init() caller to skip module idle in
_setup()
OMAP2: hwmod data: add IVA1 (2420), IVA2 (2430) hwmods
OMAP: hwmod/device: add omap_{device,hwmod}_get_mpu_rt_va
OMAP2+: hwmod/device: update documentation and copyright
OMAP: PM constraints: add return values; add requesting device param to
omap_pm_set_max_dev_wakeup_lat()
OMAP: PM constraints: add omap_pm_set_min_clk_rate()
Rajendra Nayak (1):
OMAP4: hwmod: Enable omap_device build for OMAP4
arch/arm/mach-omap1/Kconfig |6 +
arch/arm/mach-omap1/clock.c | 22 +++--
arch/arm/mach-omap1/clock.h |2 +-
arch/arm/mach-omap1/clock_data.c | 129 +++-
arch/arm/mach-omap2/Makefile |4 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/cm.c |6 +-
arch/arm/mach-omap2/io.c | 11 ++-
arch/arm/mach-omap2/omap_hwmod.c | 106 +++-
arch/arm/mach-omap2/omap_hwmod_2420_data.c| 79 +++-
arch/arm/mach-omap2/omap_hwmod_2430_data.c| 81 +++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 92 --
arch/arm/mach-omap2/omap_hwmod_common_data.c |3 +
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
arch/arm/mach-omap2/pm.c | 84
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/i2c.c | 12 ++-
arch/arm/plat-omap/include/plat/clock.h | 130
-
arch/arm/plat-omap/include/plat/common.h |4 +
arch/arm/plat-omap/include/plat/omap-pm.h | 130
+++--
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 14 ++-
arch/arm/plat-omap/omap-pm-noop.c | 61 +---
arch/arm/plat-omap/omap_device.c | 33 ++-
24 files changed, 790 insertions(+), 225 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm.c
--
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] Adding LogicPD OMAP 3530 LV SOM and OMAP 35x Torpedo
Hi, * Jacob Tanenbaum jacob.tanenb...@logicpd.com [100526 16:30]: Adding LogicPD OMAP3 board support Adding support for LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo board. Please update this patch to leave out the defconfig as we won't be patching those any longer as requested by Linus. Instead, please just add default y for the board in arch/arm/mach-omap2/Kconfig. Please also test these patches with the linux-omap for-next branch. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH 1/3] omap: rx51: Add platform_data for tlv320aic3x with
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: devel-boards Initial commit ID (Likely to change): 47c7cdf07979102128ff4056416135c994690263 PatchWorks http://patchwork.kernel.org/patch/102348/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=47c7cdf07979102128ff4056416135c994690263 -- 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: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@nokia.com]
Sent: Tuesday, July 06, 2010 3:36 PM
To: Hiremath, Vaibhav
Cc: Grazvydas Ignotas; linux-fb...@vger.kernel.org; linux-
o...@vger.kernel.org; Valkeinen Tomi (Nokia-MS/Helsinki)
Subject: Re: [PATCH] OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC
On Tue, Jul 06, 2010 at 08:08:14AM +0200, ext Hiremath, Vaibhav wrote:
@@ -648,6 +649,17 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int
cmd,
unsigned long arg)
r = -EFAULT;
break;
+ case FBIO_WAITFORVSYNC:
+ if (get_user(p.crt, (__u32 __user *)arg)) {
+ r = -EFAULT;
+ break;
+ }
+ if (p.crt != 0) {
+ r = -ENODEV;
+ break;
+ }
+ /* FALLTHROUGH */
+
case OMAPFB_WAITFORVSYNC:
[Hiremath, Vaibhav] I don't see any reason why we should still keep old
custom IOCTL support here.
It can already be used so it should not be removed.
[Hiremath, Vaibhav] I am not in favor of this, if we have standard interface
then we should encourage people to use it. Don't you think we will have
different interface for OMAP and different for non-omap device.
Thanks,
Vaibhav
--
Ville Syrjälä
--
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: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC
On Tue, Jul 06, 2010 at 01:26:28PM +0200, ext Hiremath, Vaibhav wrote:
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@nokia.com]
Sent: Tuesday, July 06, 2010 3:36 PM
To: Hiremath, Vaibhav
Cc: Grazvydas Ignotas; linux-fb...@vger.kernel.org; linux-
o...@vger.kernel.org; Valkeinen Tomi (Nokia-MS/Helsinki)
Subject: Re: [PATCH] OMAP: DSS2: OMAPFB: add support for FBIO_WAITFORVSYNC
On Tue, Jul 06, 2010 at 08:08:14AM +0200, ext Hiremath, Vaibhav wrote:
@@ -648,6 +649,17 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int
cmd,
unsigned long arg)
r = -EFAULT;
break;
+ case FBIO_WAITFORVSYNC:
+ if (get_user(p.crt, (__u32 __user *)arg)) {
+ r = -EFAULT;
+ break;
+ }
+ if (p.crt != 0) {
+ r = -ENODEV;
+ break;
+ }
+ /* FALLTHROUGH */
+
case OMAPFB_WAITFORVSYNC:
[Hiremath, Vaibhav] I don't see any reason why we should still keep old
custom IOCTL support here.
It can already be used so it should not be removed.
[Hiremath, Vaibhav] I am not in favor of this, if we have standard interface
then we should encourage people to use it. Don't you think we will have
different interface for OMAP and different for non-omap device.
What anyone thinks that apps should do doesn't matter. Removing the
ioctl will break the ABI and that is not an acceptable thing to do in
kernel development usually.
--
Ville Syrjälä
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/15] omap zoom2: wlan board muxing
* Ohad Ben-Cohen o...@wizery.com [100706 03:37]: From: Ohad Ben-Cohen oh...@ti.com Add board muxing to support the wlan wl1271 chip that is hardwired to mmc2 (third mmc controller) on the ZOOM2. I'll pick this and following patch into omap for-next. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
On Tue, Jul 6, 2010 at 1:22 PM, Ohad Ben-Cohen o...@wizery.com wrote: Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better. Some correction and additional info: The wl1271 device has an issue which makes the standard card detect mechanism irrelevant: it is always up, even if the power enable gpio input of the device is down (the power enable input does not supply the power to the chip, it's just logical digital high/low input upon which the device reacts). That's why we must use software control for emulating card detect with that device. In addition, as far as I could find out, the card detect mechanism on the ZOOM is implemented by mechanical means, and thus is not relevant for hardwired embedded SDIO devices (I'm not even sure card detect is supported for the 3rd mmc controller). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
On Tue, Jul 6, 2010 at 2:02 PM, Roger Quadros roger.quad...@nokia.com wrote: On 07/06/2010 01:22 PM, ext Ohad Ben-Cohen wrote: We prefer not to power up the chip as early as boot time; instead, we Why? Let's say you boot your device but never use WLAN. In this scenario, we prefer the wl1271 device to stay powered off to minimize power consumption. This way we will power on the wl1271 device only when the user actually turns WLAN on. The function driver should power it down later if required. no? Care to explain this ? I'm not sure I'm following: the sdio function is added and the sdio driver is probed only after you power on the wl1271 device and let the mmc layer initialize and configure it. Why would you want to do that if WLAN is disabled (i.e. user didn't turn wlan on) ? If it was powered OFF then how did the wlan interface come into picture? As soon as you insmod wl1271 and wl1271_sdio, you will have a wlan interface (which is still down). At this point the wl1271 device is still powered off and not consuming power. If the user chooses to enable wlan (i.e. ifconfig wlan0 up), the chip is powered on, it is initialized and configured by the mmc layer, and then it can be used for WLAN activities. I agree, we some how need to power down the card when not in use in the right way. In this patchset proposal, as soon as the user disables wlan (i.e. ifconfig wlan0 down), the wl1271 device is powered off, and the corresponding sdio function is removed. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/15] omap: zoom: add WLAN device
Hi Ohad,
On 07/06/2010 03:37 AM, ext Ohad Ben-Cohen wrote:
From: Ohad Ben-Cohenoh...@ti.com
Add WLAN platform device and control
functions (power and virtual card detect)
in order to allow software to control the
embedded SDIO WLAN device which resides on
the ZOOM board (TI's wl1271 device).
Based on Android's WLAN control functions by
San Mehats...@android.com.
Signed-off-by: Ohad Ben-Cohenoh...@ti.com
---
arch/arm/mach-omap2/board-zoom-wlan.c | 129 +
arch/arm/mach-omap2/include/mach/board-zoom.h |5 +
2 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c
diff --git a/arch/arm/mach-omap2/board-zoom-wlan.c
b/arch/arm/mach-omap2/board-zoom-wlan.c
new file mode 100644
index 000..7ed5139
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-wlan.c
@@ -0,0 +1,129 @@
+/* mach-omap2/board-zoom-wlan.c
+ *
+ * Board support for wl1271 embedded SDIO device.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#includelinux/kernel.h
+#includelinux/init.h
+#includelinux/platform_device.h
+#includelinux/mmc/host.h
+#includelinux/mmc/sdio_ids.h
+#includelinux/err.h
+#includelinux/gpio.h
+#includelinux/wl12xx.h
+
+#include mux.h
+
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+
+/* these are zoom-specific board numbers */
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
+
+/* wl1271 virtual 'card detect' status */
+static int omap_zoom_wlan_cd;
+static void (*wlan_set_virtual_cd)(void *dev_id, int card_present);
+static void (*wlan_set_data)(void *dev_id, void *priv);
+static void *wlan_host_devid;
+
+int omap_zoom_wlan_register_embedded_control(void *dev_id,
+ void (*set_virtual_cd)(void *dev_id, int card_present),
+ void (*set_data)(void *dev_id, void *priv))
+{
+ if (wlan_host_devid || wlan_set_virtual_cd || wlan_set_data)
+ return -EBUSY;
+
+ wlan_set_virtual_cd = set_virtual_cd;
+ wlan_set_data = set_data;
+ wlan_host_devid = dev_id;
+
+ return 0;
+}
+
+int omap_zoom_wlan_get_virtual_cd(void)
+{
+ return omap_zoom_wlan_cd;
+}
+
+static void omap_zoom_wlan_set_embedded_data(void *priv)
+{
+ if (wlan_set_data)
+ wlan_set_data(wlan_host_devid, priv);
+ else
+ pr_err(%s: host controller not registered yet\n, __func__);
+}
+
+static void omap_zoom_wlan_set_carddetect(bool card_present)
+{
+ omap_zoom_wlan_cd = card_present ? 1 : 0;
+
+ pr_info(%s: %d\n, __func__, omap_zoom_wlan_cd);
+
+ if (wlan_set_virtual_cd)
+ wlan_set_virtual_cd(wlan_host_devid, omap_zoom_wlan_cd);
+ else
+ pr_err(%s: host controller not registered yet\n, __func__);
+}
+
+static void omap_zoom_wlan_power(bool enable)
+{
+ int val = enable ? 1 : 0;
+
+ pr_info(%s: set power %d\n, __func__, val);
+
+ gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
+}
Can we consider that OMAP_ZOOM_WLAN_PMENA_GPIO is equivalent to vmmc supply or
equivalent to supply voltage to the SDIO card?
If yes, then did you consider using the fixed regulator framework to define a
'vmmc' supply (based on OMAP_ZOOM_WLAN_PMENA_GPIO). Then the SDIO/MMC core
should take care of controlling this supply.
regards,
-roger
--
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 9/9] omap: id: add feature check for omap1
* Nishanth Menon n...@ti.com [100623 05:10]: add a minimalist feature - l2cache for omap1. Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap1/id.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c index 91dbb71..b98a17f 100644 --- a/arch/arm/mach-omap1/id.c +++ b/arch/arm/mach-omap1/id.c @@ -200,5 +200,11 @@ void __init omap1_check_revision(void) printk(KERN_INFO revision %i handled as %02xxx id: %08x%08x\n, die_rev, omap_revision 0xff, system_serial_low, system_serial_high); + + /* + * TODO: add a better check feature once we have + * more decent feature check + */ + omap_features |= OMAP_HAS_L2CACHE; } There's no L2 cache on omap1? 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 11/15] wireless: wl1271: introduce platform device support
Hi Roger, On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros roger.quad...@nokia.com wrote: My point is that shouldn't this be handled by SDIO core? Care to explain what you mean / give a code example ? If there are no users for the SDIO function and the card, doesn't the SDIO core power down the slot and take care of re-initialization when it is powered up? You need card detect events in order to trigger card sdio function initialization and removals. Please share any alternative approach you may be thinking on. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] omap: id: add feature check for omap1
On 07/06/2010 07:46 AM, Tony Lindgren wrote: * Nishanth Menonn...@ti.com [100623 05:10]: add a minimalist feature - l2cache for omap1. Signed-off-by: Nishanth Menonn...@ti.com --- arch/arm/mach-omap1/id.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c index 91dbb71..b98a17f 100644 --- a/arch/arm/mach-omap1/id.c +++ b/arch/arm/mach-omap1/id.c @@ -200,5 +200,11 @@ void __init omap1_check_revision(void) printk(KERN_INFO revision %i handled as %02xxx id: %08x%08x\n, die_rev, omap_revision 0xff, system_serial_low, system_serial_high); + + /* +* TODO: add a better check feature once we have +* more decent feature check +*/ + omap_features |= OMAP_HAS_L2CACHE; } There's no L2 cache on omap1? I thought it did, hence added.. am I wrong? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] omap: id: add feature check for omap1
* Nishanth Menon n...@ti.com [100706 15:47]: On 07/06/2010 07:46 AM, Tony Lindgren wrote: * Nishanth Menonn...@ti.com [100623 05:10]: add a minimalist feature - l2cache for omap1. Signed-off-by: Nishanth Menonn...@ti.com --- arch/arm/mach-omap1/id.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c index 91dbb71..b98a17f 100644 --- a/arch/arm/mach-omap1/id.c +++ b/arch/arm/mach-omap1/id.c @@ -200,5 +200,11 @@ void __init omap1_check_revision(void) printk(KERN_INFO revision %i handled as %02xxx id: %08x%08x\n, die_rev, omap_revision 0xff, system_serial_low, system_serial_high); + + /* +* TODO: add a better check feature once we have +* more decent feature check +*/ + omap_features |= OMAP_HAS_L2CACHE; } There's no L2 cache on omap1? I thought it did, hence added.. am I wrong? Maybe you're thinking something else.. But for example, 1710 TRM says: ARM926EJ L1 32K-byte, four-way set-associative instruction cache L1 16K-byte, four-way set-associative data cache with write buffer Then 2430 TRM says: ARM1136JF-S 32K-byte instructions and 32K-byte data--4-way associative 64-entry instruction and 64-entry data memory management units (MMUs) So no L2 until 34xx I believe. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH:v4 00/13] OMAP: GPIO: Implement GPIO in HWMOD way
* Charulatha V ch...@ti.com [100622 17:55]: This patch series makes OMAP2PLUS specific GPIO implemented in HWMOD FW way. This is done by implementing GPIO module in platform device model. This patch series is generated on origin/pm-wip/hwmods-omap4. Do we still have a dependency on this series to pm-wip? Can you please try to rebase this on top of linux-omap for-next branch? Let's see if we can merge this into linux-omap master branch for some testing before we merge it. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: mux: fix multipath gpio handling
* Grazvydas Ignotas nota...@gmail.com [100705 23:00]: OMAP3530 CBB package can have GPIO126 muxed on 2 pins: mmc1_dat4 and cam_strobe. This causes a problem with current multipath GPIO mux handling, which muxes both pins as GPIO126 and makes the GPIO unusable. Fix this by not muxing any pins if multipath GPIO is detected and just print a warning instead. It's up to board files to set correct mux using omap_mux_init_signal and pin name. This looks good to me. Are you OK if we merge it during the upcoming merge window? Kind of worried that we might break some other boards that rely on the first GPIO getting muxed.. 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 05/15] omap: hsmmc: add virtual card detect support
On Tue, Jul 6, 2010 at 3:39 PM, Roger Quadros roger.quad...@nokia.com wrote: Just to clarify, is the wl1271 device always powered on the board? Yes. And this GPIO power enable (OMAP_ZOOM_WLAN_PMENA_GPIO) is used to gate this supply internally? Yes. It's a digital input that the chip does not draw current from (well, only a very minimal one). and what do these do ? set_bit(WL1271_FLAG_GPIO_POWER, wl-flags); clear_bit(WL1271_FLAG_GPIO_POWER, wl-flags); This is an internal driver bit that maintains the power state of the chip. AFAICT, it does not do anything. The only place I can see it is being used is in a debugfs entry. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/15] omap: zoom: add WLAN device
Hi Roger,
On Tue, Jul 6, 2010 at 3:33 PM, Roger Quadros roger.quad...@nokia.com wrote:
+static void omap_zoom_wlan_power(bool enable)
+{
+ int val = enable ? 1 : 0;
+
+ pr_info(%s: set power %d\n, __func__, val);
+
+ gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
+}
Can we consider that OMAP_ZOOM_WLAN_PMENA_GPIO is equivalent to vmmc supply
or equivalent to supply voltage to the SDIO card?
Not really, this gpio does not supply power to the chip. It's only a
digital indication that instructs the chip to go into on or off mode.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: mux: fix multipath gpio handling
On Tue, Jul 6, 2010 at 4:25 PM, Tony Lindgren t...@atomide.com wrote: * Grazvydas Ignotas nota...@gmail.com [100705 23:00]: OMAP3530 CBB package can have GPIO126 muxed on 2 pins: mmc1_dat4 and cam_strobe. This causes a problem with current multipath GPIO mux handling, which muxes both pins as GPIO126 and makes the GPIO unusable. Fix this by not muxing any pins if multipath GPIO is detected and just print a warning instead. It's up to board files to set correct mux using omap_mux_init_signal and pin name. This looks good to me. Are you OK if we merge it during the upcoming merge window? Kind of worried that we might break some other boards that rely on the first GPIO getting muxed.. Yeah that should be fine, no need to rush. -- 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 11/15] wireless: wl1271: introduce platform device support
On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote: Hi Roger, On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadrosroger.quad...@nokia.com wrote: My point is that shouldn't this be handled by SDIO core? Care to explain what you mean / give a code example ? If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then the SDIO/MMC core should tackle it, just like it deals with supply for slots with removable cards. see mmc_regulator_set_ocr() mmc_power_up() mmc_set_ios() in drivers/mmc/core/core.c and omap_hsmmc_set_ios() in drivers/mmc/host/omap_hsmmc.c If there are no users for the SDIO function and the card, doesn't the SDIO core power down the slot and take care of re-initialization when it is powered up? You need card detect events in order to trigger card sdio function initialization and removals. Please share any alternative approach you may be thinking on. OK, this is how I see it. - Treat the non-removable card as non-removable. So no need to do card detect emulation. - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator framework to define this regulator supply. Even though you mention that it is not actually a supply, it fits well in the fixed supply framework. - When the host controller is enumerated, the mmc core will power up the slot, find the sdio card, and probe the function driver (i.e. wl1271_sdio). - if interface is not in use, the function driver must release the sdio host, and this should eventually disable the vmmc supply. - Whenever the wlan interface must be brought up, wl1271_sdio, can claim the sdio host. this will cause the vmmc supply to be enabled, for as long as the interface is up. Does this address all issues? regards, -roger -- 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/3] omap4: Add basic suspend support
This series is based of linux-omap for-next branch,also applies to the latest 2.6.35-rc4 and is targeted for 2.6.36 merge window It adds basic supsend and cpu hotplug support so that CONFIG_PM can be enabled on all OMAP4 platforms. This is essential to keep build working after Tony's omap Kconfig improvments for 2.6.36 merge window series http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31303.html The following changes since commit e3dc03cb09a37ce61534c5922d3d383465f5e2ed: Tony Lindgren (1): omap: Add back UART MDR1 check into uncompress.h are available in the git repository at: origin/for-next Rajendra Nayak (1): omap4: suspend: Add basic system suspend support Santosh Shilimkar (2): omap4: Add smc API to read AuxCoreBoot0 register omap4: hotplug: Add basic CPU hotplug support arch/arm/mach-omap2/Makefile|2 + arch/arm/mach-omap2/include/mach/omap4-common.h |7 + arch/arm/mach-omap2/omap-headsmp.S | 16 --- arch/arm/mach-omap2/omap-hotplug.c | 79 + arch/arm/mach-omap2/omap-smp.c |3 +- arch/arm/mach-omap2/omap44xx-smc.S | 25 arch/arm/mach-omap2/pm44xx.c| 135 +++ arch/arm/plat-omap/include/plat/smp.h |1 + 8 files changed, 251 insertions(+), 17 deletions(-) create mode 100644 arch/arm/mach-omap2/omap-hotplug.c create mode 100644 arch/arm/mach-omap2/pm44xx.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] omap4: suspend: Add basic system suspend support
From: Rajendra Nayak rna...@ti.com
This patch adds support for basic suspend doing a CPUx wfi
for OMAP4. All powerdomains are for now are kept programmed
in ON state.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/pm44xx.c | 135 ++
2 files changed, 136 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm44xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0efcc94..3cb1b51 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -49,6 +49,7 @@ ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
new file mode 100644
index 000..54544b4
--- /dev/null
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -0,0 +1,135 @@
+/*
+ * OMAP4 Power Management Routines
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/pm.h
+#include linux/suspend.h
+#include linux/module.h
+#include linux/list.h
+#include linux/err.h
+#include linux/slab.h
+
+#include plat/powerdomain.h
+#include mach/omap4-common.h
+
+struct power_state {
+ struct powerdomain *pwrdm;
+ u32 next_state;
+#ifdef CONFIG_SUSPEND
+ u32 saved_state;
+#endif
+ struct list_head node;
+};
+
+static LIST_HEAD(pwrst_list);
+
+#ifdef CONFIG_SUSPEND
+static int omap4_pm_prepare(void)
+{
+ disable_hlt();
+ return 0;
+}
+
+static int omap4_pm_suspend(void)
+{
+ do_wfi();
+ return 0;
+}
+
+static int omap4_pm_enter(suspend_state_t suspend_state)
+{
+ int ret = 0;
+
+ switch (suspend_state) {
+ case PM_SUSPEND_STANDBY:
+ case PM_SUSPEND_MEM:
+ ret = omap4_pm_suspend();
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+static void omap4_pm_finish(void)
+{
+ enable_hlt();
+ return;
+}
+
+static int omap4_pm_begin(suspend_state_t state)
+{
+ return 0;
+}
+
+static void omap4_pm_end(void)
+{
+ return;
+}
+
+static struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap4_pm_begin,
+ .end= omap4_pm_end,
+ .prepare= omap4_pm_prepare,
+ .enter = omap4_pm_enter,
+ .finish = omap4_pm_finish,
+ .valid = suspend_valid_only_mem,
+};
+#endif /* CONFIG_SUSPEND */
+
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
+{
+ struct power_state *pwrst;
+
+ if (!pwrdm-pwrsts)
+ return 0;
+
+ pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
+ if (!pwrst)
+ return -ENOMEM;
+ pwrst-pwrdm = pwrdm;
+ pwrst-next_state = PWRDM_POWER_ON;
+ list_add(pwrst-node, pwrst_list);
+
+ return pwrdm_set_next_pwrst(pwrst-pwrdm, pwrst-next_state);
+}
+
+/**
+ * omap4_pm_init - Init routine for OMAP4 PM
+ *
+ * Initializes all powerdomain and clockdomain target states
+ * and all PRCM settings.
+ */
+static int __init omap4_pm_init(void)
+{
+ int ret;
+
+ if (!cpu_is_omap44xx())
+ return -ENODEV;
+
+ pr_err(Power Management for TI OMAP4.\n);
+
+#ifdef CONFIG_PM
+ ret = pwrdm_for_each(pwrdms_setup, NULL);
+ if (ret) {
+ pr_err(Failed to setup powerdomains\n);
+ goto err2;
+ }
+#endif
+
+#ifdef CONFIG_SUSPEND
+ suspend_set_ops(omap_pm_ops);
+#endif /* CONFIG_SUSPEND */
+
+err2:
+ return ret;
+}
+late_initcall(omap4_pm_init);
--
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
[PATCH 2/3] omap4: Add smc API to read AuxCoreBoot0 register
This patch adds a secure API to read AuxCoreBoot0 register to
check the cpu boot status. It also moves the other smc APIs
to common omap44xx-smc.S. This APIs should not be marked as
__INIT because we need these to be present for CPU hotplug
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap-headsmp.S| 16
arch/arm/mach-omap2/omap44xx-smc.S| 25 +
arch/arm/plat-omap/include/plat/smp.h |1 +
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-headsmp.S
b/arch/arm/mach-omap2/omap-headsmp.S
index ef0e7a0..6ae937a 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -47,19 +47,3 @@ hold:ldr r12,=0x103
b secondary_startup
END(omap_secondary_startup)
-
-ENTRY(omap_modify_auxcoreboot0)
- stmfd sp!, {r1-r12, lr}
- ldr r12, =0x104
- dsb
- smc #0
- ldmfd sp!, {r1-r12, pc}
-END(omap_modify_auxcoreboot0)
-
-ENTRY(omap_auxcoreboot_addr)
- stmfd sp!, {r2-r12, lr}
- ldr r12, =0x105
- dsb
- smc #0
- ldmfd sp!, {r2-r12, pc}
-END(omap_auxcoreboot_addr)
diff --git a/arch/arm/mach-omap2/omap44xx-smc.S
b/arch/arm/mach-omap2/omap44xx-smc.S
index f61c777..1980dc3 100644
--- a/arch/arm/mach-omap2/omap44xx-smc.S
+++ b/arch/arm/mach-omap2/omap44xx-smc.S
@@ -30,3 +30,28 @@ ENTRY(omap_smc1)
smc #0
ldmfd sp!, {r2-r12, pc}
END(omap_smc1)
+
+ENTRY(omap_modify_auxcoreboot0)
+ stmfd sp!, {r1-r12, lr}
+ ldr r12, =0x104
+ dsb
+ smc #0
+ ldmfd sp!, {r1-r12, pc}
+END(omap_modify_auxcoreboot0)
+
+ENTRY(omap_auxcoreboot_addr)
+ stmfd sp!, {r2-r12, lr}
+ ldr r12, =0x105
+ dsb
+ smc #0
+ ldmfd sp!, {r2-r12, pc}
+END(omap_auxcoreboot_addr)
+
+ENTRY(omap_read_auxcoreboot0)
+ stmfd sp!, {r2-r12, lr}
+ ldr r12, =0x103
+ dsb
+ smc #0
+ mov r0, r0, lsr #9
+ ldmfd sp!, {r2-r12, pc}
+END(omap_read_auxcoreboot0)
diff --git a/arch/arm/plat-omap/include/plat/smp.h
b/arch/arm/plat-omap/include/plat/smp.h
index 8983d54..6a3ff65 100644
--- a/arch/arm/plat-omap/include/plat/smp.h
+++ b/arch/arm/plat-omap/include/plat/smp.h
@@ -30,6 +30,7 @@
extern void omap_secondary_startup(void);
extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
extern void omap_auxcoreboot_addr(u32 cpu_addr);
+extern u32 omap_read_auxcoreboot0(void);
/*
* We use Soft IRQ1 as the IPI
--
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
[PATCH 3/3] omap4: hotplug: Add basic CPU hotplug support
This patch adds cpu hotplug support for OMAP4430. Only CPU inactive
state is supported as a low power state in the basic hot-plug support
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/include/mach/omap4-common.h |7 ++
arch/arm/mach-omap2/omap-hotplug.c | 79 +++
arch/arm/mach-omap2/omap-smp.c |3 +-
4 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap-hotplug.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3cb1b51..0db90ff 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
# SMP support ONLY available for OMAP4
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o
+obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o
AFLAGS_omap44xx-smc.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index 423af3a..2744dfe 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -13,6 +13,13 @@
#ifndef OMAP_ARCH_OMAP4_COMMON_H
#define OMAP_ARCH_OMAP4_COMMON_H
+/*
+ * wfi used in low power code. Directly opcode is used instead
+ * of instruction to avoid mulit-omap build break
+ */
+#define do_wfi() \
+ __asm__ __volatile__ (.word0xe320f003 : : : memory)
+
#ifdef CONFIG_CACHE_L2X0
extern void __iomem *l2cache_base;
#endif
diff --git a/arch/arm/mach-omap2/omap-hotplug.c
b/arch/arm/mach-omap2/omap-hotplug.c
new file mode 100644
index 000..6cee456
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -0,0 +1,79 @@
+/*
+ * OMAP4 SMP cpu-hotplug support
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Author:
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Platform file needed for the OMAP4 SMP. This file is based on arm
+ * realview smp platform.
+ * Copyright (c) 2002 ARM Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/smp.h
+#include linux/completion.h
+
+#include asm/cacheflush.h
+#include mach/omap4-common.h
+
+static DECLARE_COMPLETION(cpu_killed);
+
+int platform_cpu_kill(unsigned int cpu)
+{
+ return wait_for_completion_timeout(cpu_killed, 5000);
+}
+
+/*
+ * platform-specific code to shutdown a CPU
+ * Called with IRQs disabled
+ */
+void platform_cpu_die(unsigned int cpu)
+{
+ unsigned int this_cpu = hard_smp_processor_id();
+
+ if (cpu != this_cpu) {
+ pr_crit(platform_cpu_die running on %u, should be %u\n,
+ this_cpu, cpu);
+ BUG();
+ }
+ pr_notice(CPU%u: shutdown\n, cpu);
+ complete(cpu_killed);
+ flush_cache_all();
+ dsb();
+
+ /*
+* we're ready for shutdown now, so do it
+*/
+ if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
+ printk(KERN_CRIT Secure clear status failed\n);
+
+ for (;;) {
+ /*
+* Execute WFI
+*/
+ do_wfi();
+
+ if (omap_read_auxcoreboot0() == cpu) {
+ /*
+* OK, proper wakeup, we're done
+*/
+ break;
+ }
+ pr_debug(CPU%u: spurious wakeup call\n, cpu);
+ }
+}
+
+int platform_cpu_disable(unsigned int cpu)
+{
+ /*
+* we don't allow CPU 0 to be shutdown (it is still too special
+* e.g. clock tick interrupts)
+*/
+ return cpu == 0 ? -EPERM : 0;
+}
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 1cf5231..af3c20c 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -73,9 +73,10 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
* the AuxCoreBoot1 register is updated with cpu state
* A barrier is added to ensure that write buffer is drained
*/
- omap_modify_auxcoreboot0(0x200, 0x0);
+ omap_modify_auxcoreboot0(0x200, 0xfdff);
flush_cache_all();
smp_wmb();
+ smp_cross_call(cpumask_of(cpu));
/*
* Now the secondary core is starting up let it run its
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH] staging: tidspbridge: gen: simplify and clean up
There is recently added hex_to_bin() kernel's method which we could use
instead of custom long function.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: linux-omap@vger.kernel.org
---
drivers/staging/tidspbridge/gen/uuidutil.c | 167 +---
1 files changed, 28 insertions(+), 139 deletions(-)
diff --git a/drivers/staging/tidspbridge/gen/uuidutil.c
b/drivers/staging/tidspbridge/gen/uuidutil.c
index ce9319d..eb09bc3 100644
--- a/drivers/staging/tidspbridge/gen/uuidutil.c
+++ b/drivers/staging/tidspbridge/gen/uuidutil.c
@@ -54,61 +54,19 @@ void uuid_uuid_to_string(IN struct dsp_uuid *uuid_obj, OUT
char *pszUuid,
DBC_ENSURE(i != -1);
}
-/*
- * htoi
- * Purpose:
- * Converts a hex value to a decimal integer.
- */
-
-static int htoi(char c)
+static s32 uuid_hex_to_bin(char *buf, s32 len)
{
- switch (c) {
- case '0':
- return 0;
- case '1':
- return 1;
- case '2':
- return 2;
- case '3':
- return 3;
- case '4':
- return 4;
- case '5':
- return 5;
- case '6':
- return 6;
- case '7':
- return 7;
- case '8':
- return 8;
- case '9':
- return 9;
- case 'A':
- return 10;
- case 'B':
- return 11;
- case 'C':
- return 12;
- case 'D':
- return 13;
- case 'E':
- return 14;
- case 'F':
- return 15;
- case 'a':
- return 10;
- case 'b':
- return 11;
- case 'c':
- return 12;
- case 'd':
- return 13;
- case 'e':
- return 14;
- case 'f':
- return 15;
+ s32 i;
+ s32 result = 0;
+
+ for (i = 0; i len; i++) {
+ value = hex_to_bin(*buf++);
+ result *= 16;
+ if (value 0)
+ result += value;
}
- return 0;
+
+ return result;
}
/*
@@ -118,106 +76,37 @@ static int htoi(char c)
*/
void uuid_uuid_from_string(IN char *pszUuid, OUT struct dsp_uuid *uuid_obj)
{
- char c;
- s32 i, j;
- s32 result;
- char *temp = pszUuid;
+ s32 j;
- result = 0;
- for (i = 0; i 8; i++) {
- /* Get first character in string */
- c = *temp;
-
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-ul_data1 = result;
+ uuid_obj-ul_data1 = uuid_hex_to_bin(pszUuid, 8);
+ pszUuid += 8;
/* Step over underscore */
- temp++;
+ pszUuid++;
- result = 0;
- for (i = 0; i 4; i++) {
- /* Get first character in string */
- c = *temp;
-
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-us_data2 = (u16) result;
+ uuid_obj-us_data2 = (u16) uuid_hex_to_bin(pszUuid, 4);
+ pszUuid += 4;
/* Step over underscore */
- temp++;
-
- result = 0;
- for (i = 0; i 4; i++) {
- /* Get first character in string */
- c = *temp;
+ pszUuid++;
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-us_data3 = (u16) result;
+ uuid_obj-us_data3 = (u16) uuid_hex_to_bin(pszUuid, 4);
+ pszUuid += 4;
/* Step over underscore */
- temp++;
-
- result = 0;
- for (i = 0; i 2; i++) {
- /* Get first character in string */
- c = *temp;
+ pszUuid++;
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
+ uuid_obj-uc_data4 = (u8) uuid_hex_to_bin(pszUuid, 2);
+ pszUuid += 2;
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-uc_data4 = (u8) result;
-
- result = 0;
- for (i = 0; i 2; i++) {
- /* Get first character in string */
- c = *temp;
-
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-uc_data5 = (u8) result;
+ uuid_obj-uc_data5 = (u8) uuid_hex_to_bin(pszUuid,
RE: [PATCH 05/15] omap: hsmmc: add virtual card detect support
-Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Tuesday, July 06, 2010 6:48 AM To: Nicolas Pitre Cc: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Luciano Coelho; Andrew Morton; San Mehat; Pandita, Vikram Subject: Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support On Tue, Jul 6, 2010 at 1:22 PM, Ohad Ben-Cohen o...@wizery.com wrote: Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better. Some correction and additional info: The wl1271 device has an issue which makes the standard card detect mechanism irrelevant: it is always up, even if the power enable gpio input of the device is down (the power enable input does not supply the power to the chip, it's just logical digital high/low input upon which the device reacts). That's why we must use software control for emulating card detect with that device. In addition, as far as I could find out, the card detect mechanism on the ZOOM is implemented by mechanical means, and thus is not relevant for hardwired embedded SDIO devices (I'm not even sure card detect is supported for the 3rd mmc controller). The card detect is supported through T2 GPIO interrupts only for MMC1 and MMC2. Such a mechanism is not present for MMC3 to which the WLAN chip is hardwired. Regards, Madhu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
This patch contains the documentation for the API, termed the Virtual Contiguous Memory Manager. Its use would allow all of the IOMMU to VM, VM to device and device to IOMMU interoperation code to be refactored into platform independent code. Comments, suggestions and criticisms are welcome and wanted. Signed-off-by: Zach Pfeffer zpfef...@codeaurora.org --- Documentation/vcm.txt | 587 + 1 files changed, 587 insertions(+), 0 deletions(-) create mode 100644 Documentation/vcm.txt diff --git a/Documentation/vcm.txt b/Documentation/vcm.txt new file mode 100644 index 000..1c6a8be --- /dev/null +++ b/Documentation/vcm.txt @@ -0,0 +1,587 @@ +What is this document about? + + +This document covers how to use the Virtual Contiguous Memory Manager +(VCMM), how the first implementation works with a specific low-level +Input/Output Memory Management Unit (IOMMU) and the way the VCMM is used +from user-space. It also contains a section that describes why something +like the VCMM is needed in the kernel. + +If anything in this document is wrong, please send patches to the +maintainer of this file, listed at the bottom of the document. + + +The Virtual Contiguous Memory Manager += + +The VCMM was built to solve the system-wide memory mapping issues that +occur when many bus-masters have IOMMUs. + +An IOMMU maps device addresses to physical addresses. It also insulates +the system from spurious or malicious device bus transactions and allows +fine-grained mapping attribute control. The Linux kernel core does not +contain a generic API to handle IOMMU mapped memory; device driver writers +must implement device specific code to interoperate with the Linux kernel +core. As the number of IOMMUs increases, coordinating the many address +spaces mapped by all discrete IOMMUs becomes difficult without in-kernel +support. + +The VCMM API enables device independent IOMMU control, virtual memory +manager (VMM) interoperation and non-IOMMU enabled device interoperation +by treating devices with or without IOMMUs and all CPUs with or without +MMUs, their mapping contexts and their mappings using common +abstractions. Physical hardware is given a generic device type and mapping +contexts are abstracted into Virtual Contiguous Memory (VCM) +regions. Users reserve memory from VCMs and back their reservations +with physical memory. + +Why the VCMM is Needed +-- + +Driver writers who control devices with IOMMUs must contend with device +control and memory management. Driver writers have a large device driver +API that they can leverage to control their devices, but they are lacking +a unified API to help them program mappings into IOMMUs and share those +mappings with other devices and CPUs in the system. + +Sharing is complicated by Linux's CPU-centric VMM. The CPU-centric model +generally makes sense because average hardware only contains a MMU for the +CPU and possibly a graphics MMU. If every device in the system has one or +more MMUs the CPU-centric memory management (MM) programming model breaks +down. + +Abstracting IOMMU device programming into a common API has already begun +in the Linux kernel. It was built to abstract the difference between AMD +and Intel IOMMUs to support x86 virtualization on both platforms. The +interface is listed in include/linux/iommu.h. It contains +interfaces for mapping and unmapping as well as domain management. This +interface has not gained widespread use outside the x86; PA-RISC, Alpha +and SPARC architectures and ARM and PowerPC platforms all use their own +mapping modules to control their IOMMUs. The VCMM contains an IOMMU +programming layer, but since its abstraction supports map management +independent of device control, the layer is not used directly. This +higher-level view enables a new kernel service, not just an IOMMU +interoperation layer. + +The General Idea: Map Management using Graphs +- + +Looking at mapping from a system-wide perspective reveals a general graph +problem. The VCMM's API is built to manage the general mapping graph. Each +node that talks to memory, either through an MMU or directly (physically +mapped) can be thought of as the device-end of a mapping edge. The other +edge is the physical memory (or intermediate virtual space) that is +mapped. + +In the direct-mapped case the device is assigned a one-to-one MMU. This +scheme allows direct mapped devices to participate in general graph +management. + +The CPU nodes can also be brought under the same mapping abstraction with +the use of a light overlay on the existing VMM. This light overlay allows +VMM-managed mappings to interoperate with the common API. The light +overlay enables this without substantial modifications to the existing +VMM. + +In addition to CPU nodes that are running Linux (and the VMM), remote CPU +nodes that may be
[RFC 2/3] mm: iommu: A physical allocator for the VCMM
The Virtual Contiguous Memory Manager (VCMM) needs a physical pool to
allocate from. It breaks up the pool into sub-pools of same-sized
chunks. In particular, it breaks the pool it manages into sub-pools of
1 MB, 64 KB and 4 KB chunks.
When a user makes a request, this allocator satisfies that request
from the sub-pools using a maximum-munch strategy. This strategy
attempts to satisfy a request using the largest chunk-size without
over-allocating, then moving on to the next smallest size without
over-allocating and finally completing the request with the smallest
sized chunk, over-allocating if necessary.
The maximum-munch strategy allows physical page allocation for small
TLBs that need to map a given range using the minimum number of mappings.
Although the allocator has been configured for 1 MB, 64 KB and 4 KB
chunks, it can be easily extended to other chunk sizes.
Signed-off-by: Zach Pfeffer zpfef...@codeaurora.org
---
arch/arm/mm/vcm_alloc.c | 425 +
include/linux/vcm_alloc.h | 70
2 files changed, 495 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mm/vcm_alloc.c
create mode 100644 include/linux/vcm_alloc.h
diff --git a/arch/arm/mm/vcm_alloc.c b/arch/arm/mm/vcm_alloc.c
new file mode 100644
index 000..e592e71
--- /dev/null
+++ b/arch/arm/mm/vcm_alloc.c
@@ -0,0 +1,425 @@
+/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/vcm_alloc.h
+#include linux/string.h
+#include asm/sizes.h
+
+/* Amount of memory managed by VCM */
+#define TOTAL_MEM_SIZE SZ_32M
+
+static unsigned int base_pa = 0x8000;
+int basicalloc_init;
+
+int chunk_sizes[NUM_CHUNK_SIZES] = {SZ_1M, SZ_64K, SZ_4K};
+int init_num_chunks[] = {
+ (TOTAL_MEM_SIZE/2) / SZ_1M,
+ (TOTAL_MEM_SIZE/4) / SZ_64K,
+ (TOTAL_MEM_SIZE/4) / SZ_4K
+};
+#define LAST_SZ() (ARRAY_SIZE(chunk_sizes) - 1)
+
+#define vcm_alloc_err(a, ...) \
+ pr_err(ERROR %s %i a, __func__, __LINE__, ##__VA_ARGS__)
+
+struct phys_chunk_head {
+ struct list_head head;
+ int num;
+};
+
+struct phys_mem {
+ struct phys_chunk_head heads[ARRAY_SIZE(chunk_sizes)];
+} phys_mem;
+
+static int is_allocated(struct list_head *allocated)
+{
+ /* This should not happen under normal conditions */
+ if (!allocated) {
+ vcm_alloc_err(no allocated\n);
+ return 0;
+ }
+
+ if (!basicalloc_init) {
+ vcm_alloc_err(no basicalloc_init\n);
+ return 0;
+ }
+ return !list_empty(allocated);
+}
+
+static int count_allocated_size(enum chunk_size_idx idx)
+{
+ int cnt = 0;
+ struct phys_chunk *chunk, *tmp;
+
+ if (!basicalloc_init) {
+ vcm_alloc_err(no basicalloc_init\n);
+ return 0;
+ }
+
+ list_for_each_entry_safe(chunk, tmp,
+phys_mem.heads[idx].head, list) {
+ if (is_allocated(chunk-allocated))
+ cnt++;
+ }
+
+ return cnt;
+}
+
+
+int vcm_alloc_get_mem_size(void)
+{
+ return TOTAL_MEM_SIZE;
+}
+EXPORT_SYMBOL(vcm_alloc_get_mem_size);
+
+
+int vcm_alloc_blocks_avail(enum chunk_size_idx idx)
+{
+ if (!basicalloc_init) {
+ vcm_alloc_err(no basicalloc_init\n);
+ return 0;
+ }
+
+ return phys_mem.heads[idx].num;
+}
+EXPORT_SYMBOL(vcm_alloc_blocks_avail);
+
+
+int vcm_alloc_get_num_chunks(void)
+{
+ return ARRAY_SIZE(chunk_sizes);
+}
+EXPORT_SYMBOL(vcm_alloc_get_num_chunks);
+
+
+int vcm_alloc_all_blocks_avail(void)
+{
+ int i;
+ int cnt = 0;
+
+ if (!basicalloc_init) {
+ vcm_alloc_err(no basicalloc_init\n);
+ return 0;
+ }
+
+ for (i = 0; i ARRAY_SIZE(chunk_sizes); ++i)
+ cnt += vcm_alloc_blocks_avail(i);
+ return cnt;
+}
+EXPORT_SYMBOL(vcm_alloc_all_blocks_avail);
+
+
+int vcm_alloc_count_allocated(void)
+{
+ int i;
+ int cnt = 0;
+
+ if (!basicalloc_init) {
+ vcm_alloc_err(no basicalloc_init\n);
+ return 0;
+ }
+
+ for (i = 0; i
Re: [PATCH 04/15] mmc: support embedded data field in mmc_host
On Tue, Jul 6, 2010 at 3:37 AM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Ohad Ben-Cohen oh...@ti.com
Add support to set/get mmc_host private embedded
data.
This is needed to allow software to dynamically
create (and remove) SDIO functions which represents
embedded SDIO devices.
Typically, it will be used to set the context of
a driver that is creating a new SDIO function
(and would then expect to be able to get that context
back upon creation of the new sdio func).
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/mmc/core/Kconfig | 8
include/linux/mmc/host.h | 16
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index bb22ffd..ab27eb3 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME
This option sets a default which can be overridden by the
module parameter removable=0 or removable=1.
+
+config MMC_EMBEDDED_SDIO
+ boolean MMC embedded SDIO device support
+ help
+ If you say Y here, support will be added for embedded SDIO
+ devices (e.g. hardwired embedded WLAN SDIO devices).
+ Such devices require software support for emulating
+ card detect events.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f65913c..9a48486 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -209,6 +209,10 @@ struct mmc_host {
struct led_trigger *led; /* activity led */
#endif
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+ void *embedded_data;
+#endif
+
Hm, do we really need a Kconfig option just for a single pointer? It
only saves sizeof(void *) bytes per host, but adds rather confusing
config option for users and some ifdef complexity.
--
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 11/11] staging: ti dspbridge: enable driver building
On 7/4/2010 5:53 AM, Felipe Contreras wrote: On Thu, Jun 24, 2010 at 1:41 AM, Greg KHg...@kroah.com wrote: The default is always 'n' so you don't need this. Also, this enables the driver to be built on x86, which fails horribly, and I don't think is what you really want to have happen :) So I need some more Kconfig changes here, care to redo just this one patch? I've applied all the others and they will show up in linux-next tomorrow. I fixed all that stuff some time ago: http://article.gmane.org/gmane.linux.ports.arm.omap/36065 But the patches were ignored. Patches were not ignored, discussion was held privately (you and me), patch 13 was not accepted because changing indentation doesn't deserve a copyright assignment (IMHO), at that point *you* wanted your patches not to be included if the last one wasn't merged in. - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/15] mmc: support embedded data field in mmc_host
On Tue, Jul 6, 2010 at 6:49 PM, Grazvydas Ignotas nota...@gmail.com wrote: Hm, do we really need a Kconfig option just for a single pointer? It only saves sizeof(void *) bytes per host, but adds rather confusing config option for users and some ifdef complexity. No strong feelings about it, I can remove that if preferred. -- 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] Add OMAP4 Panda Support
Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, July 05, 2010 6:52 AM To: Anders, David Cc: Gadiyar, Anand; linux-omap@vger.kernel.org Subject: Re: [PATCH] Add OMAP4 Panda Support * Anders, David x0132...@ti.com [100628 20:41]: Tony, If there are no objections, can we get someone to signoff on this so we can get it in the window? I've added default y to Kconfig for Panda and queued this patch. Updated patch below. Tony Thanks a bunch, I really appreciate it! 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 9/9] omap: id: add feature check for omap1
Tony Lindgren had written, on 07/06/2010 08:14 AM, the following: * Nishanth Menon n...@ti.com [100706 15:47]: On 07/06/2010 07:46 AM, Tony Lindgren wrote: * Nishanth Menonn...@ti.com [100623 05:10]: add a minimalist feature - l2cache for omap1. Signed-off-by: Nishanth Menonn...@ti.com --- arch/arm/mach-omap1/id.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c index 91dbb71..b98a17f 100644 --- a/arch/arm/mach-omap1/id.c +++ b/arch/arm/mach-omap1/id.c @@ -200,5 +200,11 @@ void __init omap1_check_revision(void) printk(KERN_INFO revision %i handled as %02xxx id: %08x%08x\n, die_rev, omap_revision 0xff, system_serial_low, system_serial_high); + + /* +* TODO: add a better check feature once we have +* more decent feature check +*/ + omap_features |= OMAP_HAS_L2CACHE; } There's no L2 cache on omap1? I thought it did, hence added.. am I wrong? Maybe you're thinking something else.. But for example, 1710 TRM says: ARM926EJ L1 32K-byte, four-way set-associative instruction cache L1 16K-byte, four-way set-associative data cache with write buffer Then 2430 TRM says: ARM1136JF-S 32K-byte instructions and 32K-byte data--4-way associative 64-entry instruction and 64-entry data memory management units (MMUs) So no L2 until 34xx I believe. Regards, Tony Arrgh.. my bad. you are right. here is a bigger list I just checked internally with TRMs 1510 - TI925T - no L2. A separate 16K-byte instruction cache and 8K-byte data cache. Both are two-way associative with virtual index virtual tag (VIVT) 1610 - ARM926EJ L1 16K-byte, four-way set-associative instruction cache L1 8K-byte, four-way set-associative data cache with write buffer 1710 - ARM926EJ L1 32K-byte, four-way set-associative instruction cache L1 16K-byte, four-way set-associative data cache with write buffer 2420 (2.3) - ARM1136JF-S – 32-KB instruction and 32-KB data; 4-way set associative memory management units (MMUs) – 64-entry instruction and 64-entry data write buffer 2430 (2.1) - – 32K-byte instructions and 32K-byte data—4-way associative – 64-entry instruction and 64-entry data memory management units (MMUs) Please drop 9/9, and I will post a new revision of 8/9 without L2 enabled. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8 v2] omap: introduce omap24xx generic features
introduce generic features for omap2. omap2 uses mbx, not sgx, and
it still has a dsp, though not iva2 as omap3 uses..
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: comments from http://marc.info/?t=12772595613r=1w=2n=4
incorporated - L2 cache is removed from enabled features for omap2.
V1: original patch including L2 cache being set as available feature
arch/arm/mach-omap2/id.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index e3f5994..ab8eb41 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -102,6 +102,15 @@ static struct omap_id omap_ids[] __initdata = {
static void __iomem *tap_base;
static u16 tap_prod_id;
+static void __init omap24xx_check_features(void)
+{
+ /*
+* TODO: add a better check feature once we have
+* more decent feature check
+*/
+ omap_features |= OMAP_HAS_IVA;
+}
+
static void __init omap24xx_check_revision(void)
{
int i, j;
@@ -388,6 +397,7 @@ void __init omap2_check_revision(void)
*/
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
+ omap24xx_check_features();
} else if (cpu_is_omap34xx()) {
omap3_check_revision();
omap3_check_features();
--
1.6.3.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 05/15] omap: hsmmc: add virtual card detect support
On Tue, 6 Jul 2010, Madhusudhan wrote: -Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Tuesday, July 06, 2010 6:48 AM To: Nicolas Pitre Cc: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Luciano Coelho; Andrew Morton; San Mehat; Pandita, Vikram Subject: Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support On Tue, Jul 6, 2010 at 1:22 PM, Ohad Ben-Cohen o...@wizery.com wrote: Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better. Some correction and additional info: The wl1271 device has an issue which makes the standard card detect mechanism irrelevant: it is always up, even if the power enable gpio input of the device is down (the power enable input does not supply the power to the chip, it's just logical digital high/low input upon which the device reacts). That's why we must use software control for emulating card detect with that device. In addition, as far as I could find out, the card detect mechanism on the ZOOM is implemented by mechanical means, and thus is not relevant for hardwired embedded SDIO devices (I'm not even sure card detect is supported for the 3rd mmc controller). The card detect is supported through T2 GPIO interrupts only for MMC1 and MMC2. Such a mechanism is not present for MMC3 to which the WLAN chip is hardwired. Many existing implementations simply have no (or a broken) card detection signal. In that case, either the host controller passes the MMC_CAP_NEEDS_POLL flag to the core so that the bus is probed on a regular interval for card presence. Or, like in this case where the card is always hardwired on the board, you simply rely on the initial probe which is always performed at least once when the host controller driver is registered. Now the issue of having the card powered off when not in use is a valid one, whether or not it is actually hardwired on the board or hot insertable/removable. This fake insertion thing is not the best way to go about it. It would be way more useful, generic, and less hackish to simply improve the generic code so to power down the card when it is 1) not claimed by any function driver, and 2) provide an API to let a function driver signify to the core and host controller that it is not interested by the hardware at the moment (if the network interface is not up for example) and therefore the core could again power down the card. This would work in all cases with no need for exceptions for so called enbedded controllers. Nicolas -- 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 11/15] wireless: wl1271: introduce platform device support
On Tue, 6 Jul 2010, Roger Quadros wrote: On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote: Hi Roger, On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadrosroger.quad...@nokia.com wrote: My point is that shouldn't this be handled by SDIO core? Care to explain what you mean / give a code example ? If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then the SDIO/MMC core should tackle it, just like it deals with supply for slots with removable cards. Exact. You need card detect events in order to trigger card sdio function initialization and removals. Why would you trigger function initialization and removal? Just to turn off power? That's a bit like pulling off the battery from your laptop when you want to suspend it. There is a better way to go about things. Please share any alternative approach you may be thinking on. OK, this is how I see it. - Treat the non-removable card as non-removable. So no need to do card detect emulation. - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator framework to define this regulator supply. Even though you mention that it is not actually a supply, it fits well in the fixed supply framework. - When the host controller is enumerated, the mmc core will power up the slot, find the sdio card, and probe the function driver (i.e. wl1271_sdio). - if interface is not in use, the function driver must release the sdio host, and this should eventually disable the vmmc supply. - Whenever the wlan interface must be brought up, wl1271_sdio, can claim the sdio host. this will cause the vmmc supply to be enabled, for as long as the interface is up. Does this address all issues? This is mostly all good, except that claiming/releasing the SDIO host is about access to the bus. It must be claimed right before doing any IO, and released right after that, even when the card is expected to remain powered. This is not the proper place to hook power control. Another function pair would be needed instead, which would do almost like the suspend/resume code is already doing. Something like: /* * Indicate to the core SDIO layer that we're not requiring that the * function remain powered. If all functions for the card are in the * same no power state, then the host controller can remove power from * the card. Note: the function driver must preserve hardware states if * necessary. */ int sdio_release_power(struct sdio_func *func); /* * Indicate to the core SDIO layer that we want power back for this * SDIO function. The power may or may not actually have been removed * since last call to sdio_release_power(), so the function driver must * not assume any preserved state at the hardware level and re-perform * all the necessary hardware config. This function returns 0 when * power is actually restored, or some error code if this cannot be * achieved. One error reason might be that the card is no longer * available on the bus (was removed while powered down and card * detection didn't trigger yet). */ int sdio_claim_power(struct sdio_func *func); That's it. When the network interface is down and the hardware is not needed, you call sdio_release_power(). When the request to activate the network interface is received, you call sdio_claim_power() and configure the hardware appropriately. If sdio_claim_power() returns an error, then you just return an error to the network request, and eventually the driver's remove method will be called if this is indeed because the card was removed. In the core SDIO code, this is almost identical to a suspend/resume request, except that the request comes from the function driver instead of the core MMC code. Nicolas -- 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 v.3] omap: hwspinlock: Added hwspinlock driver
Thanks Santosh, I have responded to your feedback. +#include plat/hwspinlock.h + No need of new line here. +#include plat/omap_device.h +#include plat/omap_hwmod.h Alright I will fix that. +/* Initialization function */ +int __init hwspinlocks_init(void) Since it's only init, can this go to arch/arm/mach-omap2/omap4-commin.c ? No, since it uses local #defines, we would prefer to put it in its own file. + if (retval == HWSPINLOCK_BUSY) + pm_runtime_put(handle-pdev-dev); What resource is getting release with above ?? That was a mistake actually. It should not be called because the device will be locked by the time that code is reached. Simon -- 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 11/15] wireless: wl1271: introduce platform device support
Nicolas Pitre wrote:
On Tue, 6 Jul 2010, Roger Quadros wrote:
On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
Hi Roger,
On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadrosroger.quad...@nokia.com
wrote:
My point is that shouldn't this be handled by SDIO core?
Care to explain what you mean / give a code example ?
If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
the SDIO/MMC core should tackle it, just like it deals with supply for slots
with removable cards.
Exact.
You need card detect events in order to trigger card sdio function
initialization and removals.
Why would you trigger function initialization and removal? Just to turn
off power? That's a bit like pulling off the battery from your laptop
when you want to suspend it. There is a better way to go about things.
Please share any alternative approach you may be thinking on.
OK, this is how I see it.
- Treat the non-removable card as non-removable. So no need to do card detect
emulation.
- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
framework to define this regulator supply. Even though you mention that it
is not actually a supply, it fits well in the fixed supply framework.
- When the host controller is enumerated, the mmc core will power up the slot,
find the sdio card, and probe the function driver (i.e. wl1271_sdio).
- if interface is not in use, the function driver must release the sdio host,
and this should eventually disable the vmmc supply.
- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
sdio host. this will cause the vmmc supply to be enabled, for as long as the
interface is up.
Does this address all issues?
This is mostly all good, except that claiming/releasing the SDIO host is
about access to the bus. It must be claimed right before doing any IO,
and released right after that, even when the card is expected to remain
powered. This is not the proper place to hook power control.
Another function pair would be needed instead, which would do almost
like the suspend/resume code is already doing. Something like:
/*
* Indicate to the core SDIO layer that we're not requiring that the
* function remain powered. If all functions for the card are in the
* same no power state, then the host controller can remove power from
* the card. Note: the function driver must preserve hardware states if
* necessary.
*/
int sdio_release_power(struct sdio_func *func);
/*
* Indicate to the core SDIO layer that we want power back for this
* SDIO function. The power may or may not actually have been removed
* since last call to sdio_release_power(), so the function driver must
* not assume any preserved state at the hardware level and re-perform
* all the necessary hardware config. This function returns 0 when
* power is actually restored, or some error code if this cannot be
* achieved. One error reason might be that the card is no longer
* available on the bus (was removed while powered down and card
* detection didn't trigger yet).
*/
int sdio_claim_power(struct sdio_func *func);
That's it. When the network interface is down and the hardware is not
needed, you call sdio_release_power(). When the request to activate the
network interface is received, you call sdio_claim_power() and configure
the hardware appropriately. If sdio_claim_power() returns an error,
then you just return an error to the network request, and eventually the
driver's remove method will be called if this is indeed because the card
was removed.
In the core SDIO code, this is almost identical to a suspend/resume
request, except that the request comes from the function driver instead
of the core MMC code.
For eMMC in omap_hsmmc, this is all done via claim_host / release_host
which call -enable() / -disable() methods. omap_hsmmc makes use of
mmc_power_restore_host() which calls host-bus_ops-power_restore()
which is not implemented for SDIO, but for MMC and SD it reinitializes
the card.
Set omap2_hsmmc_info mmc[x] {.nonremovable=true, .power_saving=true} and
implement host-bus_ops-power_restore() for SDIO, then the power will
go off 9 seconds after sdio_release_host() is called. Then tweak omap_hsmmc
so that it doesn't wait 9 seconds for the SDIO case
Nicolas
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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
[RFC v.4] omap: hwspinlock: Added hwspinlock driver
Hello, This is the fourth and final RFC for the hardware spinlock driver. I have incorporated some changes and fixes based on Santosh's comments. Please give your comments. Thanks, Simon = From d4794eff60e5e509581fedaf2660b0d2d92463ab Mon Sep 17 00:00:00 2001 From: Simon Que s...@ti.com Date: Wed, 23 Jun 2010 18:40:30 -0500 Subject: [PATCH] omap: hwspinlock: Added hwspinlock driver Created driver for OMAP hardware spinlock. This driver supports: - Reserved spinlocks for internal use - Dynamic allocation of unreserved locks - Lock, unlock, and trylock functions, with or without disabling irqs/preempt - Registered as a platform device driver The device initialization uses hwmod to configure the devices. One device will be created for each hardware spinlock. It will pass spinlock register addresses to the driver. The device initialization file is: arch/arm/mach-omap2/hwspinlocks.c The driver takes in data passed in device initialization. The function hwspinlock_probe() initializes the array of spinlock structures, each containing a spinlock register address provided by the device initialization. The device driver file is: arch/arm/plat-omap/hwspinlock.c Here's an API summary: int hwspinlock_lock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will keep trying until it succeeds. This is a blocking function. int hwspinlock_trylock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will return BUSY. If it succeeds in locking, the function will return ACQUIRED. This is a non-blocking function int hwspinlock_unlock(struct hwspinlock *); Unlock a hardware spinlock. struct hwspinlock *hwspinlock_request(void); Provides for dynamic allocation of a hardware spinlock. It returns the handle to the next available (unallocated) spinlock. If no more locks are available, it returns NULL. struct hwspinlock *hwspinlock_request_specific(unsigned int); Provides for static allocation of a specific hardware spinlock. This allows the system to use a specific spinlock, identified by an ID. If the ID is invalid or if the desired lock is already allocated, this will return NULL. Otherwise it returns a spinlock handle. int hwspinlock_free(struct hwspinlock *); Frees an allocated hardware spinlock (either reserved or unreserved). Signed-off-by: Simon Que s...@ti.com --- arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/hwspinlocks.c| 71 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/Makefile |3 +- arch/arm/plat-omap/hwspinlock.c | 295 ++ arch/arm/plat-omap/include/plat/hwspinlock.h | 29 +++ arch/arm/plat-omap/include/plat/omap44xx.h |2 + 7 files changed, 402 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/hwspinlocks.c create mode 100644 arch/arm/plat-omap/hwspinlock.c create mode 100644 arch/arm/plat-omap/include/plat/hwspinlock.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 6725b3a..5f5c87b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -170,3 +170,5 @@ obj-y += $(nand-m) $(nand-y) smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o obj-y += $(smc91x-m) $(smc91x-y) + +obj-$(CONFIG_ARCH_OMAP4) += hwspinlocks.o \ No newline at end of file diff --git a/arch/arm/mach-omap2/hwspinlocks.c b/arch/arm/mach-omap2/hwspinlocks.c new file mode 100644 index 000..58a6483 --- /dev/null +++ b/arch/arm/mach-omap2/hwspinlocks.c @@ -0,0 +1,71 @@ +/* + * OMAP hardware spinlock device initialization + * + * Copyright (C) 2010 Texas Instruments. All rights reserved. + * + * Contact: Simon Que s...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/module.h +#include linux/interrupt.h +#include linux/device.h +#include linux/delay.h +#include linux/io.h +#include linux/slab.h + +#include plat/hwspinlock.h +#include plat/omap_device.h +#include plat/omap_hwmod.h + +/* Spinlock
RE: [PATCH resend 1/3] AM35x: Add musb support
Felipe Balbi wrote:
On Tue, Jul 06, 2010 at 09:57:09AM +0200, ext Tony Lindgren wrote:
Sounds like we should first fix thing before adding new code
that will make fixing the basic issues harder.
my idea to deal with this is to have a set of platform glue drivers.
So omap2430.c, blackfin.c, tusb6010 and davinci.c would become a
platform driver themselves that would instantiate musb-hdrc
platform_driver and the correct dma driver (inventra, omap, cppi, etc).
It would look something like:
#include plat/usb.h
static struct musb_hdrc_ops omap2430_musb_ops = {
.readb = generic_readb,
.readw = generic_readw,
.readl = generic_readl,
.writeb = generic_writeb,
.writew = generic_writew,
.writel = generic_writel,
};
static struct musb_platform_data omap2430_musb_data = {
.ops= omap2430_musb_ops,
.mode = -EINVAL, /* change it later */
};
static int __init omap2430_musb_probe(struct platform_device *pdev)
{
struct omap24030_musb_platform_data pdata = pdev-dev.platform_data;
musb = platform_device_alloc(musb-hdrc, -1);
/* check error */
musb-dev.parent = pdev-dev;
omap2430_musb_data.mode = pdata-mode;
/* initialize every other necessary field */
platform_device_add_data(musb, omap2430_musb_data);
dma = platform_device_alloc(dma-inventra, -1);
/* check error */
dma-dev.parent = pdev-dev;
/* add both devices */
return 0;
}
static int omap2430_musb_suspend(struct platform_device *pdev,
pm_message_t state)
{
return omap2430_musb_save_context(pdev);
}
static int omap2430_musb_resume(stuct platform_device *pdev)
{
omap2430_musb_restore_context(pdev);
}
this would allow us to factor-out save/restore context, get rid of all
exported functions (by just adding every necessary function to
musb_hdrc_ops) and compile in every single musb file in one driver and
still have it working. Boards would, then, just instantiate
musb-omap2430/musb-blackfin/musb-tusb6010/musb-davinci
platform_driver(s) and the rest would be done on runtime, since only the
driver that matches would actually probe.
How does that sound ??
Like it is done in ehci-hcd.c/ohci-hcd.c?
This looks much easier to maintain.
Do you already have a patch doing this, or would you like me to spin one
for RFC/RFT?
- Anand
--
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 v.4] omap: hwspinlock: Added hwspinlock driver
Simon, -Original Message- From: Que, Simon Sent: Wednesday, July 07, 2010 1:55 AM To: linux-omap@vger.kernel.org Cc: Kanigeri, Hari; Ohad Ben-Cohen; Shilimkar, Santosh Subject: [RFC v.4] omap: hwspinlock: Added hwspinlock driver snip Created driver for OMAP hardware spinlock. This driver supports: - Reserved spinlocks for internal use - Dynamic allocation of unreserved locks - Lock, unlock, and trylock functions, with or without disabling irqs/preempt - Registered as a platform device driver The device initialization uses hwmod to configure the devices. One device will be created for each hardware spinlock. It will pass spinlock register addresses to the driver. The device initialization file is: arch/arm/mach-omap2/hwspinlocks.c The driver takes in data passed in device initialization. The function hwspinlock_probe() initializes the array of spinlock structures, each containing a spinlock register address provided by the device initialization. The device driver file is: arch/arm/plat-omap/hwspinlock.c Here's an API summary: int hwspinlock_lock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will keep trying until it succeeds. This is a blocking function. int hwspinlock_trylock(struct hwspinlock *); Attempt to lock a hardware spinlock. If it is busy, the function will return BUSY. If it succeeds in locking, the function will return ACQUIRED. This is a non-blocking function int hwspinlock_unlock(struct hwspinlock *); Unlock a hardware spinlock. struct hwspinlock *hwspinlock_request(void); Provides for dynamic allocation of a hardware spinlock. It returns the handle to the next available (unallocated) spinlock. If no more locks are available, it returns NULL. struct hwspinlock *hwspinlock_request_specific(unsigned int); Provides for static allocation of a specific hardware spinlock. This allows the system to use a specific spinlock, identified by an ID. If the ID is invalid or if the desired lock is already allocated, this will return NULL. Otherwise it returns a spinlock handle. int hwspinlock_free(struct hwspinlock *); Frees an allocated hardware spinlock (either reserved or unreserved). The above API description also should be present in the source file. Add It on top of respective API. Signed-off-by: Simon Que s...@ti.com --- arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/hwspinlocks.c| 71 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/Makefile |3 +- arch/arm/plat-omap/hwspinlock.c | 295 ++ arch/arm/plat-omap/include/plat/hwspinlock.h | 29 +++ arch/arm/plat-omap/include/plat/omap44xx.h |2 + 7 files changed, 402 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/hwspinlocks.c create mode 100644 arch/arm/plat-omap/hwspinlock.c create mode 100644 arch/arm/plat-omap/include/plat/hwspinlock.h Apart from the documentation comments, patch looks good to me. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
