RE: [PATCHv3 12/22] OMAP3: PM: Minimizing the passing around of sr id in smartreflex.c
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, April 28, 2010 12:32 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCHv3 12/22] OMAP3: PM: Minimizing the passing around of sr
id in smartreflex.c
Thara Gopinath th...@ti.com writes:
This patch ensures that sr id is passed as a parameter only to
public APIs in smartreflex.c and other APIs in smartreflex.c
uses the omap_sr strucutres.
Signed-off-by: Thara Gopinath th...@ti.com
Good change, but...
---
arch/arm/mach-omap2/smartreflex.c | 36
+---
1 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index fffd5f7..c6942e9 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -190,16 +190,8 @@ static void sr_configure(struct omap_sr *sr)
sr-is_sr_reset = 0;
}
-static void sr_start_vddautocomp(int srid)
+static void sr_start_vddautocomp(struct omap_sr *sr)
{
- struct omap_sr *sr = _sr_lookup(srid);
-
- if (!sr) {
- pr_warning(omap_sr struct corresponding to SR%d not found\n,
- srid + 1);
- return;
- }
-
if (!sr_class || !(sr_class-enable)) {
pr_warning(smartreflex class driver not registered\n);
return;
@@ -211,30 +203,22 @@ static void sr_start_vddautocomp(int srid)
}
sr-is_autocomp_active = 1;
- if (!sr_class-enable(srid)) {
+ if (!sr_class-enable(sr-srid)) {
... the class3 layer is still taking SR ID as a parameter and it
should also just take an sr_info ptr.
Hi Kevin,
sr_info is an internal structure for smartreflex driver. The intention behind
this patch is all external API's pass the srid and internally the driver static
APIs take sr_info as parameter. I did not realize this point till now when I
was doing the actual changes and hence the late reply :-)
Regards
Thara
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Buildfailure for omap3_defconfig due to patch OMAP: RX51: Add LCD Panel support
Hi Peter, ext Peter Hüwe wrote: Hi Roger, I just wanted to inform you that your Patch OMAP: RX51: Add LCD Panel support (b499d77834ae292465f8d06bb0a88f1a647dfa1a) introduces a build failure for the omap3_defconfig. You can see the error message here: http://kisskb.ellerman.id.au/kisskb/buildresult/2601981/ This is due to the fact that omap3_defconfig has CONFIG_MACH_NOKIA_RX51=y set which enables the compilation of arch/arm/mach-omap2/board-rx51.c board-rx51.c calls rx51_video_mem_init in arch/arm/mach-omap2/board-rx51- video.c which is guarded by #if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) Unfortunately none if them is set in the omap3_defconfig. Would be nice if you could fix this :) Thanks for pointing this out. Kevin Hilman had already informed me of this earlier. The patch with the fix is here https://patchwork.kernel.org/patch/98092/ Tomi has picked up the fixed patch in his tree in the for-next branch http://gitorious.org/linux-omap-dss2/linux/commit/9585a7e56c51d224830adb29b1843310a87cd034 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: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support
On Thu, May 13, 2010 at 12:16:16PM +0530, Hemanth V wrote: - Original Message - From: Christoph Fritz chf.fr...@googlemail.com To: Dmitry Torokhov dmitry.torok...@gmail.com Cc: Jonathan Cameron ji...@cam.ac.uk; Datta, Shubhrajyoti shubhrajy...@ti.com; linux-in...@vger.kernel.org; linux-omap@vger.kernel.org Sent: Thursday, May 13, 2010 1:38 AM Subject: Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support On Wed, 2010-05-12 at 11:29 -0700, Dmitry Torokhov wrote: On Wed, May 12, 2010 at 07:15:22PM +0100, Jonathan Cameron wrote: Hi, I was wondering if you could provide a bit more detail on what this driver is actually doing? My appologies if I have missed a previous explanation. If so, please add a Documentation file to explain what is going on. The driver you have here does virtually nothing itself. It takes both its source of interrupt and read function from platform data. Given the value is always 0 or 1, I'm guessing you are simply reading a gpio pin. That makes this effectively a button and doesn't require any specific code. The fact it is a proximity sensor isn't relevant to anything other than perhaps the name. Excellent point. Maybe it should simply use gpio_keys driver with SW_FRONT_PROXIMITY code. I had a look into the datasheet, this SFH 7741 has one Schmitt trigger output: So yes, it's a key even without chatter. Output being configured as GPIO is specific to OMAP4 board, SFH7741 doesnot really mandate this. The idea behind this driver is to provide a generic interface and hooks for platform specific configuration. Realistically, what are the options though? The only sane solution is to hook it to a GPIO pin, isn't it? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/2] CMA3000 Accelerometer Driver
- Original Message - From: Jonathan Cameron ji...@cam.ac.uk Hi Hemanth, Quick comments below. I haven't commented much on the input aspects, just stuck to the more general driver aspects. Thanks for the comments, responses inline. I am hoping for some more wider review. As ever at the moment, the should this be in input question is open, but if Dmitry is happy to take it then that's fine with me. Dmitry, your thoughts on this Jonathan From d2842ba67e142e78b2554cebb01341c76b84b693 Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 30 Apr 2010 11:55:10 +0530 Subject: [PATCH] CMA3000 Accelerometer Driver This patch adds support for CMA3000 Tri-axis accelerometer, which supports Motion detect, Measurement and Free fall modes. CMA3000 supports both I2C/SPI bus for communication, currently the driver supports I2C based communication. Driver reports acceleration data through input subsystem and supports sysfs for configuration changes. This chip is currently used with OMAP4 based boards Thanks to Ossi Kauppinen ossi.kauppi...@vti.fi for the support provided during development Signed-off-by: Hemanth V heman...@ti.com --- drivers/input/misc/Kconfig |9 + drivers/input/misc/Makefile |1 + drivers/input/misc/cma3000_d0x.c | 627 ++ drivers/input/misc/cma3000_d0x.h | 46 +++ drivers/input/misc/cma3000_d0x_i2c.c | 136 include/linux/i2c/cma3000.h | 60 6 files changed, 879 insertions(+), 0 deletions(-) General convention is pick a device and name driver after it. Avoids confusion in future. I am not sure I fully understand your comment, cma3000 being the family and cma300_d0x being the specific chip create mode 100644 drivers/input/misc/cma3000_d0x.c create mode 100644 drivers/input/misc/cma3000_d0x.h create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c create mode 100644 include/linux/i2c/cma3000.h diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 16ec523..4752a00 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -319,4 +319,13 @@ config INPUT_PCAP To compile this driver as a module, choose M here: the module will be called pcap_keys. +config INPUT_CMA3000_I2C +tristate VTI CMA3000 Tri-axis accelerometer +depends on I2C +help + Say Y here if you want to use VTI CMA3000 Accelerometer + through I2C interface. + + To compile this driver as a module, choose M here: the + module will be called cma3000_dxx endif diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index a8b8485..94d6eda 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -30,4 +30,4 @@ obj-$(CONFIG_INPUT_WINBOND_CIR)+= winbond-cir.o obj-$(CONFIG_INPUT_WISTRON_BTNS)+= wistron_btns.o obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o obj-$(CONFIG_INPUT_YEALINK) += yealink.o - +obj-$(CONFIG_INPUT_CMA3000_I2C) += cma3000_d0x_i2c.o cma3000_d0x.o diff --git a/drivers/input/misc/cma3000_d0x.c b/drivers/input/misc/cma3000_d0x.c new file mode 100644 index 000..c0d0ea1 --- /dev/null +++ b/drivers/input/misc/cma3000_d0x.c @@ -0,0 +1,627 @@ +/* + * cma3000_d0x.c + * VTI CMA3000_D0x Accelerometer driver + * Supports I2C/SPI interfaces The device, might but I'm not seeing SPI here. Please clear out the define bits about i2c in the code as they aren't currently relevant. Yes, will add defines related to SPI. + * + * Copyright (C) 2010 Texas Instruments + * Author: Hemanth V heman...@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, see http://www.gnu.org/licenses/. + */ + +#include linux/interrupt.h +#include linux/delay.h +#include linux/input.h +#include linux/platform_device.h +#include linux/i2c/cma3000.h + +#include cma3000_d0x.h + +#define CMA3000_WHOAMI 0x00 +#define CMA3000_REVID 0x01 +#define CMA3000_CTRL0x02 +#define CMA3000_STATUS 0x03 +#define CMA3000_RSTR0x04 +#define CMA3000_INTSTATUS 0x05 +#define CMA3000_DOUTX 0x06 +#define CMA3000_DOUTY 0x07 +#define CMA3000_DOUTZ 0x08 +#define CMA3000_MDTHR 0x09 +#define CMA3000_MDFFTMR 0x0A +#define CMA3000_FFTHR 0x0B + +#define CMA3000_RANGE2G(1 7) +#define CMA3000_RANGE8G
Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support
On Thu, May 13, 2010 at 12:16:16PM +0530, Hemanth V wrote: - Original Message - From: Christoph Fritz chf.fr...@googlemail.com To: Dmitry Torokhov dmitry.torok...@gmail.com Cc: Jonathan Cameron ji...@cam.ac.uk; Datta, Shubhrajyoti shubhrajy...@ti.com; linux-in...@vger.kernel.org; linux-omap@vger.kernel.org Sent: Thursday, May 13, 2010 1:38 AM Subject: Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support On Wed, 2010-05-12 at 11:29 -0700, Dmitry Torokhov wrote: On Wed, May 12, 2010 at 07:15:22PM +0100, Jonathan Cameron wrote: Hi, I was wondering if you could provide a bit more detail on what this driver is actually doing? My appologies if I have missed a previous explanation. If so, please add a Documentation file to explain what is going on. The driver you have here does virtually nothing itself. It takes both its source of interrupt and read function from platform data. Given the value is always 0 or 1, I'm guessing you are simply reading a gpio pin. That makes this effectively a button and doesn't require any specific code. The fact it is a proximity sensor isn't relevant to anything other than perhaps the name. Excellent point. Maybe it should simply use gpio_keys driver with SW_FRONT_PROXIMITY code. I had a look into the datasheet, this SFH 7741 has one Schmitt trigger output: So yes, it's a key even without chatter. Output being configured as GPIO is specific to OMAP4 board, SFH7741 doesnot really mandate this. The idea behind this driver is to provide a generic interface and hooks for platform specific configuration. Realistically, what are the options though? The only sane solution is to hook it to a GPIO pin, isn't it? One option I could think of is that output could be configured directly as an interrupt line, rather than a gpio based interrupt. Yes, probably gpio would be the most used option, but it would be good to make the driver generic -- To unsubscribe from this list: send the line unsubscribe 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 0/2] McBSP changes for OMAP4 platform
On Wed, May 12, 2010 at 12:18:38PM -0500, Jorge Eduardo Candelaria wrote: The following patches enable McBSP driver to be used along with the audio driver in SDP4430 and other OMAP4 based boards. Both Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4
Hi, -Original Message- From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Gupta, Ajay Kumar Sent: Thursday, May 13, 2010 9:53 AM To: Gadiyar, Anand; m...@felipebalbi.com Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4 Hi, Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4 Felipe, Another approach to use PIO mode in opposite direction would increase the cpu loading and thus using system DMA is preferred workaround. Signed-off-by: Anand Gadiyar gadi...@ti.com Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com I think falling back to pio is better than this patch. At the cost of cpu, which certainly is not preferred. It will most likely be only one transfer. How about host mode with multiple devices connected and doing transfers? Falling back to PIO would kill the cpu. Another approach is to allocate dma channels on a transfer basis. Can you elaborate this? It might be good idea to allocate the dma channels on tarnsfer basis as Felipe Suggested. The musb driver allocates dma channels for the first 8 enabled endpoints and higher endpoints works in PIO mode. For system dma if there are more nummber of Rx endpoints enabled but not used for data Transfer you might end up having many sdma channles allocated biut not used which will Impact in the system of not utilizing the sdma channels effectively. ~Hema This is way too big of a problem. If we think of the scenarios in host mode then certainly using system DMA is best approach. -Ajay Which one is better depends on how many endpoints are doing, transfers in parallel, I suppose. I did post the a patch for the other approach (to fall back to PIO). I haven't received a response to that yet. I'm okay with either approach. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] ARM: VFP: Fixed suspend and added context save support
+ peoples who are in CC list. Janboe Ye 2010/5/13 ye janboe janboe...@gmail.com: Thanks for Russell and Tony. I think this patch is needed when MPU support OFF mode, special on omap. Otherwise, VFP state will be lost. Reviewed-by: Janboe Ye janboe...@gmail.com 2010/5/12 Russell King - ARM Linux li...@arm.linux.org.uk: On Tue, May 11, 2010 at 11:15:13AM +0800, ye janboe wrote: Is this patch ignored by you? I do not see any ack for this patch. Patch is fine, shame some of the people on the Cc haven't acked it though. Can we get acks from anyone of those, and then submit it to the patch system? Signed-off-by: Tero Kristo tero.kri...@nokia.com Cc: Vishwanath Sripathy vishwanath...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Richard Woodruff r-woodru...@ti.com Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] McBSP changes for OMAP4 platform
On Thu, 2010-05-13 at 09:19 +0100, Mark Brown wrote: On Wed, May 12, 2010 at 12:18:38PM -0500, Jorge Eduardo Candelaria wrote: The following patches enable McBSP driver to be used along with the audio driver in SDP4430 and other OMAP4 based boards. Both Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Tony, do we have you ack/sob to upstream via ASoC ? We do have a lot pending with mcbsp dependencies for ASoC atm and this would simplify upstreaming. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- To unsubscribe from this list: send the line unsubscribe 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 v5 1/5] omap3: pm: fix for twl4030 script load
-Original Message- From: Peter 'p2' De Schrijver [mailto:peter.de-schrij...@nokia.com] Sent: Tuesday, May 11, 2010 6:17 PM To: ext Lesly Arackal Manuel Cc: Valentin Eduardo (Nokia-D/Helsinki); linux-omap@vger.kernel.org; 'Lesly A M'; 'Nishanth Menon'; 'David Derrick'; 'Samuel Ortiz' Subject: Re: [PATCH v5 1/5] omap3: pm: fix for twl4030 script load Hi, Hi Eduardo, The load_twl4030_script() is called from twl4030_power_init() which is again called from twl_probe(), and this is getting called before omap3_idle_init(). So the scripts are loaded before the cpuidle is initialized. Then I don't think the system will hit sys_off before loading the scripts. Regards, Lesly Hi, I agree that in our usecase the problem can probably never happen. But what if NSLEEP2 would be controlled by some external component (Ie. not OMAP) ? I don't think we can be sure that the sleep script will not be executed while the wakeup script is not yet loaded (assuming they would be loaded in the wrong order). Note that loading the script also sets the address in the corresponding TWL4030 register. So I think this safeguard is still useful. Thanks, Peter. Hi Peter, I am not very much sure whether the MODEM(or any co processor) connected to NSLEEP2 of TRITON will assert the sleep signal, before OMAP3430(AP) boots up. So if this is confirmed, it will be better to check the order while populating the scripts. Thanks Regards, Lesly A M -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on RTL-1.4
Hi,
Another approach to use PIO mode in opposite direction would
increase
the
cpu loading and thus using system DMA is preferred workaround.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
I think falling back to pio is better than this patch.
At the cost of cpu, which certainly is not preferred.
It will most likely be only one transfer.
How about host mode with multiple devices connected and doing
transfers?
Falling back to PIO would kill the cpu.
Another approach is to allocate dma channels on a transfer basis.
Can you elaborate this?
It might be good idea to allocate the dma channels on tarnsfer basis as
Felipe
Suggested. The musb driver allocates dma channels for the first 8 enabled
endpoints and higher endpoints works in PIO mode.
For system dma if there are more nummber of Rx endpoints enabled but not
used for data
Transfer you might end up having many sdma channles allocated biut not
used which will
Impact in the system of not utilizing the sdma channels effectively.
Felipe, Is this what you meant? If so then I have a patch (copied below)
to fix this and I can post this one along with others.
-- cut here -
Currently DMA channels are allocated and they remain allocated
even if there is no active data transfer. Added channel_release()
whenever there is no pending request.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_gadget.c | 27 +--
drivers/usb/musb/musb_host.c | 14 --
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index fd842af..477a009 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -297,9 +297,13 @@ static void txstate(struct musb *musb, struct musb_request
*req)
csr);
#ifndefCONFIG_MUSB_PIO_ONLY
- if (is_dma_capable() musb_ep-dma) {
+
+ if (is_dma_capable() musb-dma_controller) {
struct dma_controller *c = musb-dma_controller;
+ if (!musb_ep-dma)
+ musb_ep-dma = c-channel_alloc(c, musb_ep-hw_ep, 1);
+
use_dma = (request-dma != DMA_ADDR_INVALID);
/* MUSB_TXCSR_P_ISO is still set correctly */
@@ -433,6 +437,7 @@ void musb_g_tx(struct musb *musb, u8 epnum)
u8 __iomem *mbase = musb-mregs;
struct musb_ep *musb_ep = musb-endpoints[epnum].ep_in;
void __iomem*epio = musb-endpoints[epnum].regs;
+ struct dma_controller *c = musb-dma_controller;
struct dma_channel *dma;
musb_ep_select(mbase, epnum);
@@ -535,6 +540,10 @@ void musb_g_tx(struct musb *musb, u8 epnum)
if (!request) {
DBG(4, %s idle now\n,
musb_ep-end_point.name);
+ if (musb_ep-dma) {
+ c-channel_release(musb_ep-dma);
+ musb_ep-dma = NULL;
+ }
return;
}
}
@@ -585,6 +594,7 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
struct usb_request *request = req-request;
struct musb_ep *musb_ep = musb-endpoints[epnum].ep_out;
void __iomem*epio = musb-endpoints[epnum].regs;
+ struct dma_controller *c = musb-dma_controller;
unsignedfifo_count = 0;
u16 len = musb_ep-packet_sz;
u16 csr = musb_readw(epio, MUSB_RXCSR);
@@ -601,8 +611,10 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
return;
}
+ if (is_dma_capable() musb-dma_controller !musb_ep-dma)
+ musb_ep-dma = c-channel_alloc(c, musb_ep-hw_ep, 0);
+
if ((is_cppi_enabled() || is_cppi41_enabled()) musb_ep-dma) {
- struct dma_controller *c = musb-dma_controller;
struct dma_channel *channel = musb_ep-dma;
/* NOTE: CPPI won't actually stop advancing the DMA
@@ -633,11 +645,9 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
if (request-actual request-length) {
#ifdef CONFIG_USB_INVENTRA_DMA
if (is_dma_capable() musb_ep-dma) {
- struct dma_controller *c;
struct dma_channel *channel;
int use_dma = 0;
- c = musb-dma_controller;
channel = musb_ep-dma;
/* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
@@ -719,7
[PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
From: Vishwanath Sripathy vishwanath...@ti.com
OMAP3430/3630 has a Silicon bug because of which SDRC is
released from IDLE even before Core DPLL has locked. This leads
to undefined behaviour of SDRC DLL.
This patch has workaround for the same.
Description of WA for 3430:
Initialization:
Disable DPLL3 automatic mode by default. Issue will not be faced as
DPLL3
is always locked.
Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
1. Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
(by changing M2 Divider value). This is increasing the period duration
of
one L3 clock cycle.
o In case of CORE is at OPP3 (166...@1.15v):
Lower the frequency to 83MHz.
o In case of CORE is at OPP2 (83...@1.05v):
Keep the frequency as it is (83MHz).
2. Increase CORE Voltage to 1.2V. This is reducing the timing duration of
the
critical path signal which will now fit to one L3 clock cycle.
3. Enable DPLL3 Automatic mode. This will ensure proper transition to
RETENTION or OFF mode.
After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
1. Disable DPLL3 Automatic mode.
2. Restore previous DPLL3 M2 Frequency and CORE Voltage values.
Description of WA for 3630:
Initialization:
Disable DPLL3 automatic mode by default. Issue will not be faced as
DPLL3 is always locked.
Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
1. Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
This is increasing the period duration of one L3 clock cycle and
reducing
the timing duration of the critical path signal which will now fit to
one
L3 clock cycle.
o In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
Lower the frequency to 100MHz.
Keep the voltage as it is (1.1375V).
o In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
Keep the frequency as it is (100MHz).
Increase the voltage to 1.1375V.
2. Enable DPLL3 Automatic mode. This will ensure proper transition to
RETENTION or OFF mode.
After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
1. Disable DPLL3 Automatic mode.
2. Restore previous DPLL3 M2 Frequency and CORE Voltage values.
Also OSWR should not be attempted if DPLL3 has locked. This should be done as
part of OSWR patch series.
Patch tested on 3430SDP and 3630 ZOOM3.
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
Index: linux-omap-pm/arch/arm/mach-omap2/pm.h
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm.h
+++ linux-omap-pm/arch/arm/mach-omap2/pm.h
@@ -60,6 +60,10 @@ struct prm_setup_vc {
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
+extern int program_vdd2_opp_3430(void);
+extern int reprogram_vdd2_opp_3430(int restore);
+extern int program_vdd2_opp_3630(void);
+extern int reprogram_vdd2_opp_3630(int restore);
extern u32 wakeup_timer_seconds;
extern struct omap_dm_timer *gptimer_wakeup;
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
@@ -56,6 +56,7 @@
#include sdrc.h
#include omap3-opp.h
+
#ifdef CONFIG_SUSPEND
static suspend_state_t suspend_state = PM_SUSPEND_ON;
static inline bool is_suspending(void)
@@ -363,6 +364,8 @@ void omap_sram_idle(void)
u32 sdrc_pwr = 0;
int per_state_modified = 0;
unsigned int start =0, end = 0;
+ u32 fclk_status = 0;
+ int restore = 1;
if (!_omap_sram_idle)
return;
@@ -415,15 +418,6 @@ void omap_sram_idle(void)
if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
omap2_clkdm_deny_idle(mpu_pwrdm-pwrdm_clkdms[0]);
- /*
-* Disable smartreflex before entering WFI.
-* Only needed if we are going to enter retention or off.
-*/
- if (mpu_next_state = PWRDM_POWER_RET)
- omap_smartreflex_disable(VDD1, 1);
- if (core_next_state = PWRDM_POWER_RET)
- omap_smartreflex_disable(VDD2, 1);
-
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
@@ -447,6 +441,31 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable smartreflex before entering WFI.
+* Only needed if
[PATCH v3 OMAP3 PM]: Remove IVA state conflict between PM and DspBridge code
From: Shweta Gulati shweta.gul...@ti.com
This version of patch incorporates review comments which includes
shifting the code change in specific function 'omap3_iva_idle' and
removing iva_pwrdm from pwrst_list rather than checking all the pwrdms
in list to exclude iva_pwrdm.
The PM code should not set latency on IVA power state based on
the flag 'enable_off_mode'.This is taken care of in this version.
Signed-off-by: Sripathy Vishwanath vishwanath...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
@@ -786,6 +786,12 @@ static void __init omap3_iva_idle(void)
OMAP3430_RST2_IVA2 |
OMAP3430_RST3_IVA2,
OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
+ /* Put the IVA2 In Idle */
+ prm_rmw_mod_reg_bits(OMAP3430_LASTPOWERSTATEENTERED_MASK, 0,
+ OMAP3430_IVA2_MOD, OMAP2_PM_PWSTCTRL);
+ /* Make Clock transition Automatic*/
+ cm_rmw_mod_reg_bits(OMAP3430_CLKTRCTRL_IVA2_MASK, 0x3,
+ OMAP3430_IVA2_MOD, OMAP2_CM_CLKSTCTRL);
}
static void __init omap3_d2d_idle(void)
@@ -1074,8 +1080,11 @@ static int __init pwrdms_setup(struct po
if (!pwrst)
return -ENOMEM;
pwrst-pwrdm = pwrdm;
- pwrst-next_state = PWRDM_POWER_RET;
- list_add(pwrst-node, pwrst_list);
+ if (strcmp(iva2_pwrdm, pwrdm-name)) {
+ pwrst-next_state = PWRDM_POWER_RET;
+ list_add(pwrst-node, pwrst_list);
+ } else
+pwrst-next_state = PWRDM_POWER_OFF;
if (pwrdm_has_hdwr_sar(pwrdm))
pwrdm_enable_hdwr_sar(pwrdm);
Index: linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/resource34xx.c
+++ linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
@@ -140,7 +140,8 @@ int set_pd_latency(struct shared_resourc
}
if (!enable_off_mode pd_lat_level == PD_LATENCY_OFF)
- pd_lat_level = PD_LATENCY_RET;
+ if (strcmp(iva2_pwrdm, pwrdm-name))
+ pd_lat_level = PD_LATENCY_RET;
resp-curr_level = pd_lat_level;
set_pwrdm_state(pwrdm, pd_lat_level);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/2] CMA3000 Accelerometer Driver
On 05/13/10 08:53, Hemanth V wrote: - Original Message - From: Jonathan Cameron ji...@cam.ac.uk Hi Hemanth, Quick comments below. I haven't commented much on the input aspects, just stuck to the more general driver aspects. Thanks for the comments, responses inline. I am hoping for some more wider review. Good luck :) As ever at the moment, the should this be in input question is open, but if Dmitry is happy to take it then that's fine with me. Dmitry, your thoughts on this Jonathan From d2842ba67e142e78b2554cebb01341c76b84b693 Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 30 Apr 2010 11:55:10 +0530 Subject: [PATCH] CMA3000 Accelerometer Driver This patch adds support for CMA3000 Tri-axis accelerometer, which supports Motion detect, Measurement and Free fall modes. CMA3000 supports both I2C/SPI bus for communication, currently the driver supports I2C based communication. Driver reports acceleration data through input subsystem and supports sysfs for configuration changes. This chip is currently used with OMAP4 based boards Thanks to Ossi Kauppinen ossi.kauppi...@vti.fi for the support provided during development Signed-off-by: Hemanth V heman...@ti.com --- drivers/input/misc/Kconfig |9 + drivers/input/misc/Makefile |1 + drivers/input/misc/cma3000_d0x.c | 627 ++ drivers/input/misc/cma3000_d0x.h | 46 +++ drivers/input/misc/cma3000_d0x_i2c.c | 136 include/linux/i2c/cma3000.h | 60 6 files changed, 879 insertions(+), 0 deletions(-) General convention is pick a device and name driver after it. Avoids confusion in future. I am not sure I fully understand your comment, cma3000 being the family and cma300_d0x being the specific chip Not true as far as VTI's website seems to say. The name of the specific chip is cma3000_d01. From previous experience (with the sca3000 series) there is a lot of variability in features in a given series from VTI (assuming there are later elements in this series). Not that I can really talk, as I called that driver after the family rather than a specific model! create mode 100644 drivers/input/misc/cma3000_d0x.c create mode 100644 drivers/input/misc/cma3000_d0x.h create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c create mode 100644 include/linux/i2c/cma3000.h diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 16ec523..4752a00 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -319,4 +319,13 @@ config INPUT_PCAP To compile this driver as a module, choose M here: the module will be called pcap_keys. +config INPUT_CMA3000_I2C + tristate VTI CMA3000 Tri-axis accelerometer + depends on I2C + help + Say Y here if you want to use VTI CMA3000 Accelerometer + through I2C interface. + + To compile this driver as a module, choose M here: the + module will be called cma3000_dxx endif diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index a8b8485..94d6eda 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -30,4 +30,4 @@ obj-$(CONFIG_INPUT_WINBOND_CIR) += winbond-cir.o obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o obj-$(CONFIG_INPUT_YEALINK)+= yealink.o - +obj-$(CONFIG_INPUT_CMA3000_I2C)+= cma3000_d0x_i2c.o cma3000_d0x.o diff --git a/drivers/input/misc/cma3000_d0x.c b/drivers/input/misc/cma3000_d0x.c new file mode 100644 index 000..c0d0ea1 --- /dev/null +++ b/drivers/input/misc/cma3000_d0x.c @@ -0,0 +1,627 @@ +/* + * cma3000_d0x.c + * VTI CMA3000_D0x Accelerometer driver + * Supports I2C/SPI interfaces The device, might but I'm not seeing SPI here. Please clear out the define bits about i2c in the code as they aren't currently relevant. Yes, will add defines related to SPI. cool, as long as you are submitting the full support for that interface as well. The usual rules of adding the hooks when they are relevant and not before apply here. + * + * Copyright (C) 2010 Texas Instruments + * Author: Hemanth V heman...@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, see http://www.gnu.org/licenses/. + */ + +#include linux/interrupt.h +#include linux/delay.h
RE: [PATCH v5 3/5] omap3: pm: Generic TRITON power scripts forOMAP3 based boards
-Original Message-
From: Peter 'p2' De Schrijver [mailto:peter.de-schrij...@nokia.com]
Sent: Monday, May 10, 2010 8:01 PM
To: Lesly A M
Cc: linux-omap@vger.kernel.org; Lesly A M; Nishanth Menon; David Derrick;
Samuel Ortiz
Subject: Re: [PATCH v5 3/5] omap3: pm: Generic TRITON power scripts
forOMAP3 based boards
On Mon, Apr 19, 2010 at 01:43:28PM +0200, ext Lesly A M wrote:
This pacth will create the generic TRITON power scripts which can be
used
by different OMAP3 boards with the same power companion chip (TWL4030
series).
Added the api(twl4030_get_scripts/twl4030_get_vc_timings) to update
the sleep/wakeup/warm_rest sequence voltsetup_time in the board file.
any reason why you use a different type for the messages sent for P3 and
P1/P2
transitions ?
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system goes into sleep.
+ * Executed upon P1_P2/P3 transition for sleep.
+ */
+static struct twl4030_ins __initdata sleep_on_seq[] = {
+ /* Broadcast message to put res to sleep */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_SLEEP),
2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_SLEEP),
2},
+};
+
+static struct twl4030_script sleep_on_script __initdata = {
+ .script = sleep_on_seq,
+ .size = ARRAY_SIZE(sleep_on_seq),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+/*
+ * Sequence to control the TRITON Power resources,
+ * when the system wakeup from sleep.
+ * Executed upon P1_P2 transition for wakeup.
+ */
+static struct twl4030_ins wakeup_p12_seq[] __initdata = {
+ /* Broadcast message to put res to active */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_ACTIVE),
2},
+};
+
+static struct twl4030_script wakeup_p12_script __initdata = {
+ .script = wakeup_p12_seq,
+ .size = ARRAY_SIZE(wakeup_p12_seq),
+ .flags = TWL4030_WAKEUP12_SCRIPT,
+};
Cheers,
Peter.
Hi Peter,
The RES_TYPE field is same for all messages.
The resource which can go to low-power mode with clk_req sig de-asserting is
configured as RES_TYPE2 = '2'. And the resource which can go to low-power
mode with sys_off sig de-asserting is configured as RES_TYPE2 = '1'.
The RES_TYPE2 is '2' for P3 wakeup and the msg will applicable for Resource
which have their TYPE2 field configured '2' (RES_VINTANA1, RES_VINTANA2,
RES_VINTDIG, VIO, RES_CLKEN, RES_HFCLKOUT).
RES_TYPE2 = '1' for P1_P2 wakeup.
(Applicable for res: RES_VPLL1, RES_VDD1, RES_VDD2, RES_REGEN,
RES_NRES_PWRON, RES_SYSEN)
Regards,
Lesly A M
--
To unsubscribe from this list: send the line unsubscribe 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] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
On Thu, May 13, 2010 at 12:09 AM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
If you are referring to this patch:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-
2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22
Yes, that's the patch. Could you make sure that the GPT8 interrupt is
generated before acking MMU fault interrupt?
I'll try tomorrow when I have access to the hw.
I tried to backport it to minimize the changes to a reproducible
test-case. I guess in the l-o branch the commit would be dd1fd0b.
Unfortunately that didn't fix the corruption. So I don't by that GPT8
theory.
- we don't need allocate memory for dummy_va_addr, if some patch should
be created should be the patch to remove dummy_va_addr allocation and
deletion.
I tried that, and that actually fixes the corruption for me (passing 0
to hw_mmu_tlb_add).
I think first page DSP side memory is never mapped to MPU side, so even if
the DSP corrupts that page it does not affect MPU side. However the right
solution is the one explained before: avoid DSP continues executing after
MMUfault.
First of all, what is the DSP supposed to do with that memory? Do we
really need to call hw_mmu_tlb_add at all?
We really, absolutely want the DSP to don't corrupt memory on ARM
side, so if we pass something, it should be full pages.
Sure, it would be nice to wait for the DSP to stop, but if for some
reason it doesn't, we need to know that the DSP doesn't have the power
to corrupt memory.
Now, I went back to commit 72110f1 and tried the patch you mentioned.
There's no GPT8 involved, and I cannot reproduce any corruption on a
beagleboard.
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -193,6 +193,7 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
u32 ulEventMask, u32 dwErrInfo)
resources);
if (MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE)) {
+ void *temp1, *temp2;
printk(KERN_INFO
bridge_deh_notify: ** DEVICE EXCEPTION
**\n);
@@ -227,8 +228,11 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
u32 ulEventMask, u32 dwErrInfo)
printk(KERN_INFO
bridge_deh_notify: DSP_MMUFAULT, fault
address = 0x%x\n, (unsigned int)fault_addr);
- dummy_va_addr =
- (u32) mem_calloc(sizeof(char) * 0x1000, MEM_PAGED);
+ temp1 = kmalloc(0x10, GFP_ATOMIC);
+ temp2 = kmalloc(0x1000, GFP_ATOMIC);
+ kfree(temp1);
+ kfree(temp2);
+ dummy_va_addr = (u32) kmalloc(0x1000, GFP_ATOMIC);
mem_physical =
VIRT_TO_PHYS(PG_ALIGN_LOW
((u32) dummy_va_addr, PG_SIZE4K));
Is there anything special I should do?
Also, wouldn't it be easier to trigger this by doing:
printk(KERN_INFO
bridge_deh_notify: DSP_MMUFAULT, fault
address = 0x%x\n, (unsigned int)fault_addr);
- dummy_va_addr =
- (u32) mem_calloc(sizeof(char) * 0x1000, MEM_PAGED);
+ temp1 = kmalloc(0x10, GFP_ATOMIC);
+ temp2 = kmalloc(0x1000, GFP_ATOMIC);
+ kfree(temp1);
mem_physical =
VIRT_TO_PHYS(PG_ALIGN_LOW
-((u32) dummy_va_addr, PG_SIZE4K));
+((u32) temp2, PG_SIZE4K));
+ kfree(temp2);
dev_context = (struct wmd_dev_context *)
deh_mgr_obj-hwmd_context;
/* Reset the dynamic mmu index to fixed count if it
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe 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 7/7] omap hsmmc: fix the hsmmc driver for am3517.
Tony Lindgren wrote:
Hi,
Some requests to make this more future proof.
* Stanley.Miao stanley.m...@windriver.com [100419 23:20]:
AM3517 don't have the register OMAP343X_CONTROL_PBIAS_LITE and the regulators
like vmmc, so we set a noop set_power function for it.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/hsmmc.c | 32
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 9ad2295..5f46797 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -139,6 +139,12 @@ static void hsmmc23_before_set_reg(struct device *dev, int
slot,
}
}
+static int am3517_mmc_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ return 0;
+}
+
Please rename this to nop_mmc_set_power or similar. Other omaps may
need it too.
Accepted.
static struct omap_mmc_platform_data *hsmmc_data[OMAP34XX_NR_MMC] __initdata;
void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
@@ -150,7 +156,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
if (cpu_is_omap2430()) {
control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
control_devconf1_offset = OMAP243X_CONTROL_DEVCONF1;
- } else {
+ } else if (!cpu_is_omap3517() !cpu_is_omap3505()) {
control_pbias_offset = OMAP343X_CONTROL_PBIAS_LITE;
control_devconf1_offset = OMAP343X_CONTROL_DEVCONF1;
}
Let's get rid of multiple cpu_is_omap tests please. Could you please
update this along the lines of something like this:
#define HSMMC_HAS_PBIAS (1 0)
#define HSMMC_HAS_WHATEVER (1 1)
...
if (!(cpu_is_omap3517() || cpu_is_omap3505())
mmc-slots[i].features |= HSMMC_HAS_PBIAS;
Accepted.
We can move other features into the variable features, such as
nonremovable, power_saving.
Stanley.
@@ -216,12 +222,25 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
*/
mmc-slots[0].ocr_mask = c-ocr_mask;
+ if (!cpu_is_omap3517() !cpu_is_omap3505()) {
+ switch (c-mmc) {
+ case 1:
+ /* on-chip level shifting via PBIAS0/PBIAS1 */
+ mmc-slots[0].before_set_reg =
hsmmc1_before_set_reg;
+ mmc-slots[0].after_set_reg =
hsmmc1_after_set_reg;
+ break;
+ case 2:
+ case 3:
+ /* off-chip level shifting, or none */
+ mmc-slots[0].before_set_reg =
hsmmc23_before_set_reg;
+ mmc-slots[0].after_set_reg = NULL;
+ break;
+ }
+ } else /* cpu_is_omap3517() || cpu_is_omap3505() */
+ mmc-slots[0].set_power = am3517_mmc_set_power;
+
Then you can test for that flag here too. When new omaps get added, it
just a question of setting the features flags right.
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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote: Figuring out a different way to do this should not limit Android at all, since Google can do what other Linux distributions do and continue to patch opportunistic suspend/suspend-block calls into their kernels as needed to ship devices, while contributing towards a different solution to the problem. I basically agree, except that despite having a year to do so none of us have come up with a different way that would actually work. Google have done this work. Who's going to prove that there is actually a different way to do this? -- Matthew Garrett | mj...@srcf.ucam.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
[PATCH 1/3] AM3517: rename the i2c boardinfo to make it more readable
There are three i2c buses on am3517, and each i2c bus has several devices
on it, so we can't name the i2c boardinfo structures with one of these
devices. In order to make it more readable, now rename these three boardinfo
structures based on i2c indexes.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
Acked-By: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 19b9e41..af383a8 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -136,7 +136,7 @@ void am3517_evm_ethernet_init(struct emac_platform_data
*pdata)
#define LCD_PANEL_BKLIGHT_PWR 182
#define LCD_PANEL_PWM 181
-static struct i2c_board_info __initdata am3517evm_i2c_boardinfo[] = {
+static struct i2c_board_info __initdata am3517evm_i2c1_boardinfo[] = {
{
I2C_BOARD_INFO(s35390a, 0x30),
.type = s35390a,
@@ -166,7 +166,7 @@ static void __init am3517_evm_rtc_init(void)
gpio_free(GPIO_RTCS35390A_IRQ);
return;
}
- am3517evm_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
+ am3517evm_i2c1_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
}
/*
@@ -177,7 +177,7 @@ static void __init am3517_evm_rtc_init(void)
static struct pca953x_platform_data am3517evm_gpio_expander_info_0 = {
.gpio_base = OMAP_MAX_GPIO_LINES,
};
-static struct i2c_board_info __initdata am3517evm_tca6416_info_0[] = {
+static struct i2c_board_info __initdata am3517evm_i2c2_boardinfo[] = {
{
I2C_BOARD_INFO(tca6416, 0x21),
.platform_data = am3517evm_gpio_expander_info_0,
@@ -191,7 +191,7 @@ static struct pca953x_platform_data
am3517evm_ui_gpio_expander_info_1 = {
static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_2 = {
.gpio_base = OMAP_MAX_GPIO_LINES + 32,
};
-static struct i2c_board_info __initdata am3517evm_ui_tca6416_info[] = {
+static struct i2c_board_info __initdata am3517evm_i2c3_boardinfo[] = {
{
I2C_BOARD_INFO(tca6416, 0x20),
.platform_data = am3517evm_ui_gpio_expander_info_1,
@@ -205,10 +205,10 @@ static struct i2c_board_info __initdata
am3517evm_ui_tca6416_info[] = {
static int __init am3517_evm_i2c_init(void)
{
omap_register_i2c_bus(1, 400, NULL, 0);
- omap_register_i2c_bus(2, 400, am3517evm_tca6416_info_0,
- ARRAY_SIZE(am3517evm_tca6416_info_0));
- omap_register_i2c_bus(3, 400, am3517evm_ui_tca6416_info,
- ARRAY_SIZE(am3517evm_ui_tca6416_info));
+ omap_register_i2c_bus(2, 400, am3517evm_i2c2_boardinfo,
+ ARRAY_SIZE(am3517evm_i2c2_boardinfo));
+ omap_register_i2c_bus(3, 400, am3517evm_i2c3_boardinfo,
+ ARRAY_SIZE(am3517evm_i2c3_boardinfo));
return 0;
}
@@ -455,8 +455,8 @@ static void __init am3517_evm_init(void)
/* RTC - S35390A */
am3517_evm_rtc_init();
- i2c_register_board_info(1, am3517evm_i2c_boardinfo,
- ARRAY_SIZE(am3517evm_i2c_boardinfo));
+ i2c_register_board_info(1, am3517evm_i2c1_boardinfo,
+ ARRAY_SIZE(am3517evm_i2c1_boardinfo));
/*Ethernet*/
am3517_evm_ethernet_init(am3517_evm_emac_pdata);
}
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] omap: init the gpio pinmux for mmc
There is two gpio for mmc use, one is for card detecting, another is
used for checking write protect. Intialize its pinmux in case the bootloader
doesn't set it.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
arch/arm/mach-omap2/devices.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 10f3a3c..3d30f22 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -591,6 +591,15 @@ static inline void omap_hsmmc_reset(void) {}
static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
int controller_nr)
{
+ if ((mmc_controller-slots[0].switch_pin 0) \
+ (mmc_controller-slots[0].switch_pin OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-slots[0].switch_pin,
+ OMAP_PIN_INPUT_PULLUP);
+ if ((mmc_controller-slots[0].gpio_wp 0) \
+ (mmc_controller-slots[0].gpio_wp OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-slots[0].gpio_wp,
+ OMAP_PIN_INPUT_PULLUP);
+
if (cpu_is_omap2420() controller_nr == 0) {
omap_cfg_reg(H18_24XX_MMC_CMD);
omap_cfg_reg(H15_24XX_MMC_CLKI);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Some am3517 related patches [V4]
Changes from V3: 1, refresh the the patches against the current omap-for-linus branch 2, Added features in mmc-slot[i]. Stanley.Miao (3): AM3517: rename the i2c boardinfo to make it more readable omap: init the gpio pinmux for mmc omap hsmmc: fix the hsmmc driver for am3517 arch/arm/mach-omap2/board-am3517evm.c | 20 ++-- arch/arm/mach-omap2/devices.c |9 + arch/arm/mach-omap2/hsmmc.c | 27 +-- arch/arm/plat-omap/include/plat/mmc.h |4 4 files changed, 44 insertions(+), 16 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: McBSP: Add 32-bit mode support
This patchs should allow to use 32-bit samples on e.g. TLV320AIC23 codec,
or others.
---
sound/soc/omap/omap-mcbsp.c | 30 ++
1 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8ad9dc9..a875d5d 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -295,8 +295,20 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
omap_mcbsp_dai_dma_params[id][substream-stream].dma_req = dma;
omap_mcbsp_dai_dma_params[id][substream-stream].port_addr = port;
omap_mcbsp_dai_dma_params[id][substream-stream].sync_mode = sync_mode;
- omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
- OMAP_DMA_DATA_TYPE_S16;
+ switch(params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S32;
+ break;
+ default:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ }
snd_soc_dai_set_dma_data(cpu_dai, substream,
omap_mcbsp_dai_dma_params[id][substream-stream]);
@@ -330,6 +342,14 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_16);
regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_16);
break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ /* Set word lengths */
+ wlen = 32;
+ regs-rcr2 |= RWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-rcr1 |= RWDLEN1(OMAP_MCBSP_WORD_32);
+ regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_32);
+ break;
default:
/* Unsupported PCM format */
return -EINVAL;
@@ -623,13 +643,15 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = {
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.capture = {\
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.ops = omap_mcbsp_dai_ops, \
.private_data = mcbsp_data[(link_id)].bus_id, \
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 1/2] usb: ehci-omap: factor out clock handling
Factor out the clock enable/disable calls in the driver for
reuse in the suspend/resume paths.
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
Based off v2.6.34-rc7 + gregkh-07-usb-2.6.34-rc7.patch
and one recent patch I posted [1]
[1] http://marc.info/?l=linux-usbm=127315680127935w=2
drivers/usb/host/ehci-omap.c | 46 +++
1 file changed, 29 insertions(+), 17 deletions(-)
Index: linux-2.6/drivers/usb/host/ehci-omap.c
===
--- linux-2.6.orig/drivers/usb/host/ehci-omap.c
+++ linux-2.6/drivers/usb/host/ehci-omap.c
@@ -190,6 +190,23 @@ struct ehci_hcd_omap {
/*-*/
+static void ehci_omap_clock_power(struct ehci_hcd_omap *omap, int on)
+{
+ if (on) {
+ clk_enable(omap-usbtll_ick);
+ clk_enable(omap-usbtll_fck);
+ clk_enable(omap-usbhost_ick);
+ clk_enable(omap-usbhost1_48m_fck);
+ clk_enable(omap-usbhost2_120m_fck);
+ } else {
+ clk_disable(omap-usbhost2_120m_fck);
+ clk_disable(omap-usbhost1_48m_fck);
+ clk_disable(omap-usbhost_ick);
+ clk_disable(omap-usbtll_fck);
+ clk_disable(omap-usbtll_ick);
+ }
+}
+
static void omap_usb_utmi_init(struct ehci_hcd_omap *omap, u8 tll_channel_mask)
{
unsigned reg;
@@ -248,27 +265,27 @@ static int omap_start_ehc(struct ehci_hc
dev_dbg(omap-dev, starting TI EHCI USB Controller\n);
- /* Enable Clocks for USBHOST */
+ /* Get all the clock handles we need */
omap-usbhost_ick = clk_get(omap-dev, usbhost_ick);
if (IS_ERR(omap-usbhost_ick)) {
+ dev_err(omap-dev, could not get usbhost_ick\n);
ret = PTR_ERR(omap-usbhost_ick);
goto err_host_ick;
}
- clk_enable(omap-usbhost_ick);
omap-usbhost2_120m_fck = clk_get(omap-dev, usbhost_120m_fck);
if (IS_ERR(omap-usbhost2_120m_fck)) {
+ dev_err(omap-dev, could not get usbhost_120m_fck\n);
ret = PTR_ERR(omap-usbhost2_120m_fck);
goto err_host_120m_fck;
}
- clk_enable(omap-usbhost2_120m_fck);
omap-usbhost1_48m_fck = clk_get(omap-dev, usbhost_48m_fck);
if (IS_ERR(omap-usbhost1_48m_fck)) {
+ dev_err(omap-dev, could not get usbhost_48m_fck\n);
ret = PTR_ERR(omap-usbhost1_48m_fck);
goto err_host_48m_fck;
}
- clk_enable(omap-usbhost1_48m_fck);
if (omap-phy_reset) {
/* Refer: ISSUE1 */
@@ -288,20 +305,22 @@ static int omap_start_ehc(struct ehci_hc
udelay(10);
}
- /* Configure TLL for 60Mhz clk for ULPI */
omap-usbtll_fck = clk_get(omap-dev, usbtll_fck);
if (IS_ERR(omap-usbtll_fck)) {
+ dev_err(omap-dev, could not get usbtll_fck\n);
ret = PTR_ERR(omap-usbtll_fck);
goto err_tll_fck;
}
- clk_enable(omap-usbtll_fck);
omap-usbtll_ick = clk_get(omap-dev, usbtll_ick);
if (IS_ERR(omap-usbtll_ick)) {
+ dev_err(omap-dev, could not get usbtll_ick\n);
ret = PTR_ERR(omap-usbtll_ick);
goto err_tll_ick;
}
- clk_enable(omap-usbtll_ick);
+
+ /* Now enable all the clocks in the correct order */
+ ehci_omap_clock_power(omap, 1);
/* perform TLL soft reset, and wait until reset is complete */
ehci_omap_writel(omap-tll_base, OMAP_USBTLL_SYSCONFIG,
@@ -428,15 +447,13 @@ static int omap_start_ehc(struct ehci_hc
return 0;
err_sys_status:
- clk_disable(omap-usbtll_ick);
+ ehci_omap_clock_power(omap, 0);
clk_put(omap-usbtll_ick);
err_tll_ick:
- clk_disable(omap-usbtll_fck);
clk_put(omap-usbtll_fck);
err_tll_fck:
- clk_disable(omap-usbhost1_48m_fck);
clk_put(omap-usbhost1_48m_fck);
if (omap-phy_reset) {
@@ -448,11 +465,9 @@ err_tll_fck:
}
err_host_48m_fck:
- clk_disable(omap-usbhost2_120m_fck);
clk_put(omap-usbhost2_120m_fck);
err_host_120m_fck:
- clk_disable(omap-usbhost_ick);
clk_put(omap-usbhost_ick);
err_host_ick:
@@ -502,32 +517,29 @@ static void omap_stop_ehc(struct ehci_hc
dev_dbg(omap-dev, operation timed out\n);
}
+ ehci_omap_clock_power(omap, 0);
+
if (omap-usbtll_fck != NULL) {
- clk_disable(omap-usbtll_fck);
clk_put(omap-usbtll_fck);
omap-usbtll_fck = NULL;
}
if (omap-usbhost_ick != NULL) {
- clk_disable(omap-usbhost_ick);
clk_put(omap-usbhost_ick);
omap-usbhost_ick = NULL;
}
if (omap-usbhost1_48m_fck != NULL) {
-
[PATCH] DSPBRIDGE: Include missing info in MMU Fault debugging trace
Some execution info is missing at the beginning of the trace buffer printout.
This fix is to include this information according to the buffer contents
description and also couple of cosmetic changes to make the traces more
readable.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/wmd/io_sm.c | 44 ---
1 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 1a5f794..f52c7b3 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -1960,9 +1960,9 @@ dsp_status print_dsp_trace_buffer(struct wmd_dev_context
*hwmd_context)
if (DSP_FAILED(status))
goto func_end;
/* Pack and do newline conversion */
- pr_info(%s: DSP Trace Buffer Begin:\n
+ pr_info(DSP Trace Buffer Begin:\n
===\n%s\n,
- __func__, psz_buf);
+ psz_buf);
/* convert to offset */
@@ -2069,6 +2069,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context
*wmd_context)
u32 size;
} mmu_fault_dbg_info;
u32 *buffer;
+ u32 *buffer_beg;
u32 *buffer_end;
u32 exc_type;
u32 i;
@@ -2078,6 +2079,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context
*wmd_context)
const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
IRP, NRP, AMR, SSR,
ILC, RILC, IER, CSR};
+ const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
struct bridge_drv_interface *intf_fxns;
struct dev_object *dev_object = wmd_context-hdev_obj;
@@ -2147,6 +2149,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context
*wmd_context)
total_size = MAX_MMU_DBGBUFF;
buffer = mem_calloc(total_size, MEM_NONPAGED);
+ buffer_beg = buffer;
buffer_end = buffer + total_size / 4;
if (!buffer) {
@@ -2166,7 +2169,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context
*wmd_context)
goto func_end;
}
- pr_err(Aproximate Crash Position:\n);
+ pr_err(\nAproximate Crash Position:\n);
pr_err(--\n);
exc_type = buffer[3];
@@ -2182,7 +2185,27 @@ dsp_status dump_dsp_stack(struct wmd_dev_context
*wmd_context)
else
pr_err(0x%-8x [Unable to match to a symbol.]\n, i);
- pr_err(Execution Info:\n);
+ buffer += 4;
+
+ pr_err(\nExecution Info:\n);
+ pr_err(---\n);
+
+ if (*buffer ARRAY_SIZE(exec_ctxt)) {
+ pr_err(Execution context \t%s\n,
+ exec_ctxt[*buffer++]);
+ } else {
+ pr_err(Execution context corrupt\n);
+ kfree(buffer_beg);
+ return -EFAULT;
+ }
+ pr_err(Task Handle\t\t0x%x\n, *buffer++);
+ pr_err(Stack Pointer\t\t0x%x\n, *buffer++);
+ pr_err(Stack Top\t\t0x%x\n, *buffer++);
+ pr_err(Stack Bottom\t\t0x%x\n, *buffer++);
+ pr_err(Stack Size\t\t0x%x\n, *buffer++);
+ pr_err(Stack Size In Use\t0x%x\n, *buffer++);
+
+ pr_err(\nCPU Registers\n);
pr_err(---\n);
for (i = 0; i 32; i++) {
@@ -2216,16 +2239,21 @@ dsp_status dump_dsp_stack(struct wmd_dev_context
*wmd_context)
if (i == 4 || i == 6 || i == 8)
pr_err(B%d 0x%-8x [Function Argument %d]\n,
i, *buffer++, i-2);
- else if (i == 15)
+ else if (i == 14)
pr_err(B14 0x%-8x [Data Page Pointer]\n,
*buffer++);
else
pr_err(B%d 0x%x\n, i, *buffer++);
}
+ pr_err(\n);
+
for (i = 0; i ARRAY_SIZE(dsp_regs); i++)
pr_err(%s 0x%x\n, dsp_regs[i], *buffer++);
+ pr_err(\nStack:\n);
+ pr_err(--\n);
+
for (i = 0; buffer buffer_end; i++, buffer++) {
if ((*buffer 0x0100) (node_find_addr(node_mgr,
*buffer , 0x600, offset_output, name) == @@
-2236,7 +2264,7 @@ dsp_status dump_dsp_stack(struct wmd_dev_context
*wmd_context)
else
pr_err([%d] 0x%x\n, i, *buffer);
}
- kfree(buffer - total_size / 4);
+
[PATCH v2 2/2] DSS2: make VRFB depends on OMAP2,3
config VRFB should depend on ARCH_OMAP2 or ARCH_OMAP3. Changes from v1: - Addressed multi-omap build issue Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com --- drivers/video/omap2/Kconfig|4 drivers/video/omap2/omapfb/Kconfig |1 - 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig index d877c36..18bb835 100644 --- a/drivers/video/omap2/Kconfig +++ b/drivers/video/omap2/Kconfig @@ -3,6 +3,10 @@ config OMAP2_VRAM config OMAP2_VRFB bool + depends on ARCH_OMAP2 || ARCH_OMAP3 + default y if FB_OMAP2 + help + OMAP VRFB buffer support is efficient for rotation source drivers/video/omap2/dss/Kconfig source drivers/video/omap2/omapfb/Kconfig diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig index a3ed15c..f186c2b 100644 --- a/drivers/video/omap2/omapfb/Kconfig +++ b/drivers/video/omap2/omapfb/Kconfig @@ -3,7 +3,6 @@ menuconfig FB_OMAP2 depends on FB OMAP2_DSS select OMAP2_VRAM - select OMAP2_VRFB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] DSS2: Allow FB_OMAP2 to build without VRFB
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/plat-omap/include/plat/vrfb.h | 16
1 file changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
b/arch/arm/plat-omap/include/plat/vrfb.h
index d8a03ce..3792bde 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,6 +35,7 @@ struct vrfb {
bool yuv_mode;
};
+#ifdef CONFIG_OMAP2_VRFB
extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
@@ -47,4 +48,19 @@ extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long
paddr,
extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
extern void omap_vrfb_restore_context(void);
+#else
+static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
+static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
+static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp) {}
+static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
+ { return 0; }
+static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
+ { return 0; }
+static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
+static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
+ { return 0; }
+static inline void omap_vrfb_restore_context(void) {}
+#endif
#endif /* __VRFB_H */
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] DSS2:Allow FB to build without VRFB
From: Senthilvadivu Guruswamy svad...@ti.com Hi all, This patch series replaces the patch DSS2 Include VRFB into omap2-3build only Thanks for the review comments. The intent of this series is to split the patch into 2 logical patches and also to incorporate the comments on multi-omap build. In this series, Kconfig is changed to have OMAP2_VRFB depend on ARCH_OMAP2 and ARCH_OMAP3. This change takes care of the multi-omap builds. This patch would allow successful build of omap_4430sdp_defconfig when OMAP2_DSS and FB_OMAP2 is enabled from menuconfig. For verification: Generated the .config on omap3_defconfig with DSS and FB enabled. Generated .config is same with and without the patch. List of Changed Files: arch/arm/plat-omap/include/plat/vrfb.h drivers/video/omap2/Kconfig drivers/video/omap2/omapfb/Kconfig Thanks, Senthil -- To unsubscribe from this list: send the line unsubscribe 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] OMAP: McBSP: Add 32-bit mode support
This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec,
or others.
Signed-off-by: Sergey Lapin sla...@ossfans.org
---
sound/soc/omap/omap-mcbsp.c | 30 ++
1 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8ad9dc9..a875d5d 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -295,8 +295,20 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
omap_mcbsp_dai_dma_params[id][substream-stream].dma_req = dma;
omap_mcbsp_dai_dma_params[id][substream-stream].port_addr = port;
omap_mcbsp_dai_dma_params[id][substream-stream].sync_mode = sync_mode;
- omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
- OMAP_DMA_DATA_TYPE_S16;
+ switch(params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S32;
+ break;
+ default:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ }
snd_soc_dai_set_dma_data(cpu_dai, substream,
omap_mcbsp_dai_dma_params[id][substream-stream]);
@@ -330,6 +342,14 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_16);
regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_16);
break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ /* Set word lengths */
+ wlen = 32;
+ regs-rcr2 |= RWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-rcr1 |= RWDLEN1(OMAP_MCBSP_WORD_32);
+ regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_32);
+ break;
default:
/* Unsupported PCM format */
return -EINVAL;
@@ -623,13 +643,15 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = {
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.capture = {\
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.ops = omap_mcbsp_dai_ops, \
.private_data = mcbsp_data[(link_id)].bus_id, \
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH] OMAP: McBSP: Add 32-bit mode support
On Thu, May 13, 2010 at 07:24:08PM +0400, Sergey Lapin wrote: This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec, or others. Signed-off-by: Sergey Lapin sla...@ossfans.org + default: + omap_mcbsp_dai_dma_params[id][substream-stream].data_type = + OMAP_DMA_DATA_TYPE_S16; + break; Defensiveness would seem to dictate returning an error here - no other sample sizes are advertised so you should never get here anyway. -- To unsubscribe from this list: send the line unsubscribe 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: [alsa-devel] [PATCH] OMAP: McBSP: Add 32-bit mode support
On Thu, May 13, 2010 at 04:27:55PM +0100, Mark Brown wrote: On Thu, May 13, 2010 at 07:24:08PM +0400, Sergey Lapin wrote: This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec, or others. Signed-off-by: Sergey Lapin sla...@ossfans.org + default: + omap_mcbsp_dai_dma_params[id][substream-stream].data_type = +OMAP_DMA_DATA_TYPE_S16; + break; Defensiveness would seem to dictate returning an error here - no other sample sizes are advertised so you should never get here anyway. Oh, and please CC maintainers on patches - adding Liam for visibility. -- To unsubscribe from this list: send the line unsubscribe 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/2] DSS2: Allow FB_OMAP2 to build without VRFB
Senthilvadivu Guruswamy had written, on 05/13/2010 10:20 AM, the following:
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/plat-omap/include/plat/vrfb.h | 16
1 file changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
b/arch/arm/plat-omap/include/plat/vrfb.h
index d8a03ce..3792bde 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,6 +35,7 @@ struct vrfb {
bool yuv_mode;
};
+#ifdef CONFIG_OMAP2_VRFB
extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
@@ -47,4 +48,19 @@ extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long
paddr,
extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
extern void omap_vrfb_restore_context(void);
+#else
+static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
+static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
+static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp) {}
+static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
+ { return 0; }
+static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
+ { return 0; }
+static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
+static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
+ { return 0; }
+static inline void omap_vrfb_restore_context(void) {}
+#endif
#endif /* __VRFB_H */
the core of the problem not solved: How do we handle the same kernel
bootup on OMAP3(vrfb) and OMAP4(tiler) if it is compile time decided?
--
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 2/3] omap3 nand: cleanup for not to use GPMC virtual address
* Sukumar Ghorai s-gho...@ti.com [100512 02:43]:
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -64,16 +64,32 @@ static void __iomem *gpmc_base;
static struct clk *gpmc_l3_clk;
-static void gpmc_write_reg(int idx, u32 val)
+void gpmc_write_reg(int idx, u32 val)
{
__raw_writel(val, gpmc_base + idx);
}
-static u32 gpmc_read_reg(int idx)
+u32 gpmc_read_reg(int idx)
{
return __raw_readl(gpmc_base + idx);
}
+void gpmc_cs_write_byte(int cs, int idx, u32 val)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
+ __raw_writeb(val, reg_addr);
+}
+
+u8 gpmc_cs_read_byte(int cs, int idx)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
+ return __raw_readb(reg_addr);
+}
+
This will not improve the situation unfortunately.
We for sure don't want to export functions to mess
with the GPMC registers all over the place.
@@ -432,15 +448,6 @@ void gpmc_prefetch_reset(void)
}
EXPORT_SYMBOL(gpmc_prefetch_reset);
-/**
- * gpmc_prefetch_status - reads prefetch status of engine
- */
-int gpmc_prefetch_status(void)
-{
- return gpmc_read_reg(GPMC_PREFETCH_STATUS);
-}
-EXPORT_SYMBOL(gpmc_prefetch_status);
-
And we don't want to remove GPMC functions like this,
instead we need to implement more functions like this
for the platform init code to use.
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 1/3] omap3: GPMC register definition at common location
* Sukumar Ghorai s-gho...@ti.com [100512 02:43]: --- a/arch/arm/plat-omap/include/plat/gpmc.h +++ b/arch/arm/plat-omap/include/plat/gpmc.h @@ -25,10 +25,40 @@ #define GPMC_CS_NAND_ADDRESS 0x20 #define GPMC_CS_NAND_DATA0x24 -#define GPMC_CONFIG 0x50 -#define GPMC_STATUS 0x54 +/* GPMC register offsets */ +#define GPMC_REVISION 0x00 +#define GPMC_SYSCONFIG 0x10 +#define GPMC_SYSSTATUS 0x14 +#define GPMC_IRQSTATUS 0x18 +#define GPMC_IRQENABLE 0x1c +#define GPMC_TIMEOUT_CONTROL0x40 +#define GPMC_ERR_ADDRESS0x44 +#define GPMC_ERR_TYPE 0x48 +#define GPMC_CONFIG 0x50 +#define GPMC_STATUS 0x54 +#define GPMC_PREFETCH_CONFIG1 0x1e0 +#define GPMC_PREFETCH_CONFIG2 0x1e4 +#define GPMC_PREFETCH_CONTROL 0x1ec +#define GPMC_PREFETCH_STATUS0x1f0 +#define GPMC_ECC_CONFIG 0x1f4 +#define GPMC_ECC_CONTROL0x1f8 +#define GPMC_ECC_SIZE_CONFIG0x1fc +#define GPMC_ECC1_RESULT0x200 ... No thanks, that will just make the situation worse leading into all the drivers messing with the GPMC registers. 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 0/3] omap3 nand: cleanup exiting platform related code
* Sukumar Ghorai s-gho...@ti.com [100512 02:43]: The following set of patches applies on top of master branch. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Patches verified on: omap3430-SDP, omap3630-sdp, zoom3 and beagle board And these are the patches required to address the following input - 1. The NAND driver needs to stop tinkering with the GPMC registers The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC. 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly. Thanks for working on this. I've made some comments to you patches to do what's listed above. Instead of exporting the GPMC registers, you should create new functions into gpmc.c for the nand platform init code to use. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: McBSP: Add 32-bit mode support
This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec,
or others.
Signed-off-by: Sergey Lapin sla...@ossfans.org
---
sound/soc/omap/omap-mcbsp.c | 28
1 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8ad9dc9..2dead3f 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -295,8 +295,18 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
omap_mcbsp_dai_dma_params[id][substream-stream].dma_req = dma;
omap_mcbsp_dai_dma_params[id][substream-stream].port_addr = port;
omap_mcbsp_dai_dma_params[id][substream-stream].sync_mode = sync_mode;
- omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
- OMAP_DMA_DATA_TYPE_S16;
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S16;
+ break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ omap_mcbsp_dai_dma_params[id][substream-stream].data_type =
+OMAP_DMA_DATA_TYPE_S32;
+ break;
+ default:
+ return -EINVAL;
+ }
snd_soc_dai_set_dma_data(cpu_dai, substream,
omap_mcbsp_dai_dma_params[id][substream-stream]);
@@ -330,6 +340,14 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_16);
regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_16);
break;
+ case SNDRV_PCM_FORMAT_S32_LE:
+ /* Set word lengths */
+ wlen = 32;
+ regs-rcr2 |= RWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-rcr1 |= RWDLEN1(OMAP_MCBSP_WORD_32);
+ regs-xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_32);
+ regs-xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_32);
+ break;
default:
/* Unsupported PCM format */
return -EINVAL;
@@ -623,13 +641,15 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = {
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.capture = {\
.channels_min = 1, \
.channels_max = 16, \
.rates = OMAP_MCBSP_RATES, \
- .formats = SNDRV_PCM_FMTBIT_S16_LE, \
+ .formats = SNDRV_PCM_FMTBIT_S16_LE |\
+ SNDRV_PCM_FMTBIT_S32_LE, \
}, \
.ops = omap_mcbsp_dai_ops, \
.private_data = mcbsp_data[(link_id)].bus_id, \
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: McBSP: Add 32-bit mode support
On Thu, May 13, 2010 at 07:48:16PM +0400, Sergey Lapin wrote: This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec, or others. Signed-off-by: Sergey Lapin sla...@ossfans.org Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault debugging trace
Ramos Falcon, Ernesto had written, on 05/13/2010 10:40 AM, the following:
Resending this patch rebased to the last changes included in dspbridge.
---
Some execution info is missing at the beginning of the
trace buffer printout. This fix is to include this information
according to the buffer contents description and
also couple of cosmetic changes to make the traces more
readable.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/core/io_sm.c | 44 +++---
1 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/dsp/bridge/core/io_sm.c b/drivers/dsp/bridge/core/io_sm.c
index d6c1a98..d11bd9f 100644
--- a/drivers/dsp/bridge/core/io_sm.c
+++ b/drivers/dsp/bridge/core/io_sm.c
@@ -1949,9 +1949,9 @@ dsp_status print_dsp_trace_buffer(struct
bridge_dev_context *hbridge_context)
if (DSP_FAILED(status))
goto func_end;
/* Pack and do newline conversion */
- pr_info(%s: DSP Trace Buffer Begin:\n
+ pr_info(DSP Trace Buffer Begin:\n
===\n%s\n,
- __func__, psz_buf);
+ psz_buf);
/* convert to offset */
@@ -2058,6 +2058,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
u32 size;
} mmu_fault_dbg_info;
u32 *buffer;
+ u32 *buffer_beg;
u32 *buffer_end;
u32 exc_type;
u32 i;
@@ -2067,6 +2068,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
IRP, NRP, AMR, SSR,
ILC, RILC, IER, CSR};
+ const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
struct bridge_drv_interface *intf_fxns;
struct dev_object *dev_object = bridge_context-hdev_obj;
@@ -2136,6 +2138,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context *bridge_context)
total_size = MAX_MMU_DBGBUFF;
buffer = kzalloc(total_size, GFP_ATOMIC);
+ buffer_beg = buffer;
buffer_end = buffer + total_size / 4;
if (!buffer) {
@@ -2155,7 +2158,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
goto func_end;
}
- pr_err(Aproximate Crash Position:\n);
+ pr_err(\nAproximate Crash Position:\n);
pr_err(--\n);
exc_type = buffer[3];
@@ -2171,7 +2174,27 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
else
pr_err(0x%-8x [Unable to match to a symbol.]\n, i);
- pr_err(Execution Info:\n);
+ buffer += 4;
+
+ pr_err(\nExecution Info:\n);
+ pr_err(---\n);
+
+ if (*buffer ARRAY_SIZE(exec_ctxt)) {
+ pr_err(Execution context \t%s\n,
+ exec_ctxt[*buffer++]);
+ } else {
+ pr_err(Execution context corrupt\n);
+ kfree(buffer_beg);
+ return -EFAULT;
+ }
+ pr_err(Task Handle\t\t0x%x\n, *buffer++);
+ pr_err(Stack Pointer\t\t0x%x\n, *buffer++);
+ pr_err(Stack Top\t\t0x%x\n, *buffer++);
+ pr_err(Stack Bottom\t\t0x%x\n, *buffer++);
+ pr_err(Stack Size\t\t0x%x\n, *buffer++);
+ pr_err(Stack Size In Use\t0x%x\n, *buffer++);
+
How about casting buffer to a structure and using it?
the use of buffer++ etc is a nightmare as can be seen here..
+ pr_err(\nCPU Registers\n);
pr_err(---\n);
btw, linux allows you to use string in a single pr_err.. e.g.
pr_err(\n CPU Registers\n
\n);
it is a bit easier on the system without going thru two function call
overhead
for (i = 0; i 32; i++) {
@@ -2205,16 +2228,21 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
if (i == 4 || i == 6 || i == 8)
pr_err(B%d 0x%-8x [Function Argument %d]\n,
i, *buffer++, i-2);
- else if (i == 15)
+ else if (i == 14)
pr_err(B14 0x%-8x [Data Page Pointer]\n,
*buffer++);
else
pr_err(B%d 0x%x\n, i, *buffer++);
}
+ pr_err(\n);
+
for (i = 0; i ARRAY_SIZE(dsp_regs); i++)
pr_err(%s 0x%x\n, dsp_regs[i], *buffer++);
+ pr_err(\nStack:\n);
+ pr_err(--\n);
+
for (i = 0; buffer buffer_end; i++, buffer++) {
RE: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault debugging trace
Ernesto
@@ -2136,6 +2138,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
total_size = MAX_MMU_DBGBUFF;
buffer = kzalloc(total_size, GFP_ATOMIC);
+ buffer_beg = buffer;
buffer_end = buffer + total_size / 4;
if (!buffer) {
-- Shouldn't this check be present before the above 2 statements ?
for (i = 0; buffer buffer_end; i++, buffer++) {
if ((*buffer 0x0100) (node_find_addr(node_mgr,
-- Is 0x0100 MAX_MMU_DBGBUFF ?
Thank you,
Best regards,
Hari
--
To unsubscribe from this list: send the line unsubscribe 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 7/7] omap hsmmc: fix the hsmmc driver for am3517.
* stanley.miao stanley.m...@windriver.com [100513 04:38]: We can move other features into the variable features, such as nonremovable, power_saving. Great, that sounds good to me. Might help with the mmc init issues for omap4 also. 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 v2 1/2] DSS2: Allow FB_OMAP2 to build without VRFB
Op 13 mei 2010, om 17:20 heeft Senthilvadivu Guruswamy het volgende geschreven:
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/plat-omap/include/plat/vrfb.h | 16
1 file changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
b/arch/arm/plat-omap/include/plat/vrfb.h
index d8a03ce..3792bde 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,6 +35,7 @@ struct vrfb {
bool yuv_mode;
};
+#ifdef CONFIG_OMAP2_VRFB
That is still a compiletime option, not a runtime check. You need something
like if(is_omap3()), not #ifdef
regards,
Koen--
To unsubscribe from this list: send the line unsubscribe 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/2] DSS2: Allow FB_OMAP2 to build without VRFB
Koen Kooi had written, on 05/13/2010 11:00 AM, the following:
Op 13 mei 2010, om 17:20 heeft Senthilvadivu Guruswamy het volgende geschreven:
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
arch/arm/plat-omap/include/plat/vrfb.h | 16
1 file changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
b/arch/arm/plat-omap/include/plat/vrfb.h
index d8a03ce..3792bde 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,6 +35,7 @@ struct vrfb {
bool yuv_mode;
};
+#ifdef CONFIG_OMAP2_VRFB
That is still a compiletime option, not a runtime check. You need something like if(is_omap3()), not #ifdef
having VRFB or tiler is a SOC feature - ideal detection should be in
id.c using the FEATURES framework.
and the actual rotation handling should be handled with function
pointers to use VRFB apis OR use tiler APIs (once it is available) to
runtime use the right rotation/other features functions runtime..
--
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 RFC 2/2] usb: ehci-omap: add suspend/resume support
On Thu, 13 May 2010, Anand Gadiyar wrote:
Add support for suspend and resume to the ehci-omap driver.
Added routines for platform_driver suspend/resume and
wrappers around ehci_bus_suspend/resume.
+#ifdef CONFIG_PM
/*-*/
+static int ehci_omap_dev_suspend(struct device *dev)
+{
+ struct ehci_hcd_omap *omap = dev_get_drvdata(dev);
+
+ if (!omap-suspended)
+ ehci_omap_enable(omap, 0);
+ return 0;
+}
+
+static int ehci_omap_dev_resume(struct device *dev)
+{
+ struct ehci_hcd_omap *omap = dev_get_drvdata(dev);
+
+ if (omap-suspended)
+ ehci_omap_enable(omap, 1);
+ return 0;
+}
+
+static int ehci_omap_bus_suspend(struct usb_hcd *hcd)
+{
+ struct usb_bus *bus = hcd_to_bus(hcd);
+ int ret;
+
+ ret = ehci_bus_suspend(hcd);
+
+ ehci_omap_dev_suspend(bus-controller);
+
+ return ret;
+}
+static int ehci_omap_bus_resume(struct usb_hcd *hcd)
+{
+ struct usb_bus *bus = hcd_to_bus(hcd);
+ int ret;
+
+ ehci_omap_dev_resume(bus-controller);
+
+ ret = ehci_bus_resume(hcd);
+
+ return ret;
+}
You could use the runtime-PM interface instead of explicitly suspending
and resuming the controller. It is now standard.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe 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] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Thursday, May 13, 2010 6:39 AM
To: Guzman Lugo, Fernando
Cc: Chitriki Rudramuni, Deepak; linux-omap; Ameya Palande; Felipe
Contreras; Hiroshi Doyu; Ramirez Luna, Omar; Menon, Nishanth
Subject: Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after
DSP_MMUFAULT
On Thu, May 13, 2010 at 12:09 AM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
If you are referring to this patch:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-
2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22
Yes, that's the patch. Could you make sure that the GPT8 interrupt is
generated before acking MMU fault interrupt?
I'll try tomorrow when I have access to the hw.
I tried to backport it to minimize the changes to a reproducible
test-case. I guess in the l-o branch the commit would be dd1fd0b.
Unfortunately that didn't fix the corruption. So I don't by that GPT8
theory.
- we don't need allocate memory for dummy_va_addr, if some patch
should
be created should be the patch to remove dummy_va_addr allocation and
deletion.
I tried that, and that actually fixes the corruption for me (passing 0
to hw_mmu_tlb_add).
I think first page DSP side memory is never mapped to MPU side, so even
if the DSP corrupts that page it does not affect MPU side. However the
right solution is the one explained before: avoid DSP continues executing
after MMUfault.
First of all, what is the DSP supposed to do with that memory? Do we
really need to call hw_mmu_tlb_add at all?
Once DSP MMUfault happens iva mmu module prevents DSP continue executing until
mmu module is able get some physical address for the virtual address that the
dsp wanted to access. Once mmu fault interrupt is acked the mmu module tries to
translate the virtual address again and if it gets the physical address DSP
continue executing. So in order to DSP can dumps its stack we need to map some
physical address to that virtual address, so that mmu release DSP and it can
dumps the stack. Therefore we allocate some dummy buffer of one 4K page and get
the physical address of that buffer and use that physical address to fill the
tbl on the mmu module using hw_mmu_tlb_add function.
However the address returned by kmalloc is not page aling, that's means this
mpu virtual address has some offset, for examples in the log that were send the
dummy address had an offset of 0x080 and the DSP side virtual memory had an
offset of 0x040. base on the offset of the MPU side and as we allocate one page
that means we can access from 0x080 - 0xfff of the first page and from 0x000 -
0x080 if the second page, but we always allocate the first page to the DSP
side, then DSP access to the address it wanted to access and now there is no
mmufault but it is accessing (actually writing because reading not cause
corruption) to that page but with a offset of 0x040 causing the corruption.
Using get_user_pages fixes that case because as it returns address page aligned
the DSP side can access from 0x000 - 0xfff of that page.
However this is not the right solution because lets suppose if DSP side virtual
address offset is 0xfff. So we map a page and DSP can access that page from
0x000 - 0xfff, however is the DSP is able to continue executing it will reach
the following page and maybe that page is already mapped but it only can access
from an specific offset like for example 0x100, in this ca DSP will still
corrupt from 0x000 to 0x0ff of the next page.
Let me recheck the changes I and will let you my findings.
Regards,
Fernando.
We really, absolutely want the DSP to don't corrupt memory on ARM
side, so if we pass something, it should be full pages.
Sure, it would be nice to wait for the DSP to stop, but if for some
reason it doesn't, we need to know that the DSP doesn't have the power
to corrupt memory.
Now, I went back to commit 72110f1 and tried the patch you mentioned.
There's no GPT8 involved, and I cannot reproduce any corruption on a
beagleboard.
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -193,6 +193,7 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
u32 ulEventMask, u32 dwErrInfo)
resources);
if (MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE)) {
+ void *temp1, *temp2;
printk(KERN_INFO
bridge_deh_notify: ** DEVICE EXCEPTION
**\n);
@@ -227,8 +228,11 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
u32 ulEventMask, u32 dwErrInfo)
printk(KERN_INFO
bridge_deh_notify: DSP_MMUFAULT, fault
address = 0x%x\n, (unsigned
int)fault_addr);
- dummy_va_addr =
- (u32)
Re: [RFC] Initial attempt to make ARM use LMB
And here's a patch which converts the OMAP FB code to use lmb_reserve instead of poking about with bootmem stuff. Untested, so I'd like to hear back whether it works. diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c index 7fc11c3..87b94a8 100644 --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -285,6 +285,7 @@ MACHINE_START(AMS_DELTA, Amstrad E3 (Delta)) .io_pg_offst= ((0xfef0) 18) 0xfffc, .boot_params= 0x1100, .map_io = ams_delta_map_io, + .reserve= omap1_reserve, .init_irq = ams_delta_init_irq, .init_machine = ams_delta_init, .timer = omap_timer, diff --git a/arch/arm/mach-omap1/board-fsample.c b/arch/arm/mach-omap1/board-fsample.c index 096f2ed..d7ea74a 100644 --- a/arch/arm/mach-omap1/board-fsample.c +++ b/arch/arm/mach-omap1/board-fsample.c @@ -378,6 +378,7 @@ MACHINE_START(OMAP_FSAMPLE, OMAP730 F-Sample) .io_pg_offst= ((0xfef0) 18) 0xfffc, .boot_params= 0x1100, .map_io = omap_fsample_map_io, + .reserve= omap1_reserve, .init_irq = omap_fsample_init_irq, .init_machine = omap_fsample_init, .timer = omap_timer, diff --git a/arch/arm/mach-omap1/board-generic.c b/arch/arm/mach-omap1/board-generic.c index e1195a3..12e2f23 100644 --- a/arch/arm/mach-omap1/board-generic.c +++ b/arch/arm/mach-omap1/board-generic.c @@ -98,6 +98,7 @@ MACHINE_START(OMAP_GENERIC, Generic OMAP1510/1610/1710) .io_pg_offst= ((0xfef0) 18) 0xfffc, .boot_params= 0x1100, .map_io = omap_generic_map_io, + .reserve= omap1_reserve, .init_irq = omap_generic_init_irq, .init_machine = omap_generic_init, .timer = omap_timer, diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c index d1100e4..616ffa8 100644 --- a/arch/arm/mach-omap1/board-h2.c +++ b/arch/arm/mach-omap1/board-h2.c @@ -467,6 +467,7 @@ MACHINE_START(OMAP_H2, TI-H2) .io_pg_offst= ((0xfef0) 18) 0xfffc, .boot_params= 0x1100, .map_io = h2_map_io, + .reserve= omap1_reserve, .init_irq = h2_init_irq, .init_machine = h2_init, .timer = omap_timer, diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c index a53ab82..bd3d037 100644 --- a/arch/arm/mach-omap1/board-h3.c +++ b/arch/arm/mach-omap1/board-h3.c @@ -437,6 +437,7 @@ MACHINE_START(OMAP_H3, TI OMAP1710 H3 board) .io_pg_offst= ((0xfef0) 18) 0xfffc, .boot_params= 0x1100, .map_io = h3_map_io, + .reserve= omap1_reserve, .init_irq = h3_init_irq, .init_machine = h3_init, .timer = omap_timer, diff --git a/arch/arm/mach-omap1/board-htcherald.c b/arch/arm/mach-omap1/board-htcherald.c index 8e313b4..8e67a10 100644 --- a/arch/arm/mach-omap1/board-htcherald.c +++ b/arch/arm/mach-omap1/board-htcherald.c @@ -304,6 +304,7 @@ MACHINE_START(HERALD, HTC Herald) .io_pg_offst= ((0xfef0) 18) 0xfffc, .boot_params= 0x1100, .map_io = htcherald_map_io, + .reserve= omap1_reserve, .init_irq = htcherald_init_irq, .init_machine = htcherald_init, .timer = omap_timer, diff --git a/arch/arm/mach-omap1/board-innovator.c b/arch/arm/mach-omap1/board-innovator.c index 5d12fd3..39bd476 100644 --- a/arch/arm/mach-omap1/board-innovator.c +++ b/arch/arm/mach-omap1/board-innovator.c @@ -463,6 +463,7 @@ MACHINE_START(OMAP_INNOVATOR, TI-Innovator) .io_pg_offst= ((0xfef0) 18) 0xfffc, .boot_params= 0x1100, .map_io = innovator_map_io, + .reserve= omap1_reserve, .init_irq = innovator_init_irq, .init_machine = innovator_init, .timer = omap_timer, diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c index 71e1a3f..615670a 100644 --- a/arch/arm/mach-omap1/board-nokia770.c +++ b/arch/arm/mach-omap1/board-nokia770.c @@ -400,6 +400,7 @@ MACHINE_START(NOKIA770, Nokia 770) .io_pg_offst= ((0xfef0) 18) 0xfffc, .boot_params= 0x1100, .map_io = omap_nokia770_map_io, + .reserve= omap1_reserve, .init_irq = omap_nokia770_init_irq, .init_machine = omap_nokia770_init, .timer = omap_timer, diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c index 80d8620..bd94eb2 100644 --- a/arch/arm/mach-omap1/board-osk.c +++ b/arch/arm/mach-omap1/board-osk.c @@ -584,6 +584,7 @@ MACHINE_START(OMAP_OSK, TI-OSK) .io_pg_offst= ((0xfef0) 18) 0xfffc, .boot_params=
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote: On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote: Figuring out a different way to do this should not limit Android at all, since Google can do what other Linux distributions do and continue to patch opportunistic suspend/suspend-block calls into their kernels as needed to ship devices, while contributing towards a different solution to the problem. I basically agree, except that despite having a year to do so none of us have come up with a different way that would actually work. Google have done this work. Who's going to prove that there is actually a different way to do this? We all feel the pain of inelegance right? I think it's clear that this system will not last (but there's no other immediate option) .. That doesn't mean we should reject it, but we need to be clear that this system will get replaced. So we should format the patches appropriately. To me the userspace aspect is a permanent change .. If we could drop that (or put it into debugfs) then it would make this a lot easy to accept as a stepping stone. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/15] omap: mailbox: reorganize init
Hi, The main purpose of this patch series is to be able to compile mach platform data as built-in. Otherwise, client modules such as bridgedriver will load the platform code, but not the mach code when mailbox is built as a module. Unfortunately, there's no easy way to do that since plat and mach code are deepely interrelated. So the first patches try to separate the mailbox registering through a defined omap_mbox_platform_data. Also, it's worth noting that mailboxes are not a one-to-one mapping to resources; that is, some resources belong to multiple mboxes. So it's best to think of mailboxes as fake devices. That is why custom platform_data is required. Finally, a bunch of cleaning up is done in the very first patches, specially for OMAP1. The initial RFC included comments from Felipe Balbi, and this proposal includes comments from Tony Lindgren. Tested on OMAP3 (beagleboard), and compiled-tested for OMAP1. Felipe Contreras (15): omap: mailbox: trivial cleanups omap: mailbox: reorganize structures omap: mailbox: 2420 should be detected at run-time omap: mailbox: use correct config for omap1 omap: mailbox: update omap1 probing omap: mailbox: reorganize registering omap: mailbox: only compile for configured archs omap: mailbox: reorganize omap platform_device omap: mailbox: move more stuff to omap_mbox_init() omap: mailbox: trivial sync between omap1 and 2 omap: mailbox: split platform driver omap: mailbox: always built-in platform data omap: mailbox: reorganize headers omap: mailbox: don't export unecessary symbols omap: mailbox: mark some resources as __initdata arch/arm/mach-omap1/Makefile |6 +- arch/arm/mach-omap1/devices.c | 40 - arch/arm/mach-omap1/mailbox.c | 114 - arch/arm/mach-omap2/Makefile |5 +- arch/arm/mach-omap2/devices.c | 74 arch/arm/mach-omap2/mailbox.c | 259 - arch/arm/plat-omap/include/plat/mailbox.h |7 +- arch/arm/plat-omap/mailbox.c | 53 +- 8 files changed, 275 insertions(+), 283 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/15] omap: mailbox: trivial cleanups
And fix a few compilation warnings.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap1/devices.c |6 ++
arch/arm/mach-omap1/mailbox.c |3 +--
arch/arm/mach-omap2/mailbox.c |7 +++
arch/arm/plat-omap/mailbox.c |2 --
4 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index a2d07aa..462b59c 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -73,12 +73,10 @@ static inline void omap_init_rtc(void) {}
# define INT_DSP_MAILBOX1 INT_1610_DSP_MAILBOX1
#endif
-#define OMAP1_MBOX_BASEOMAP1_IO_ADDRESS(OMAP16XX_MAILBOX_BASE)
-
static struct resource mbox_resources[] = {
{
- .start = OMAP1_MBOX_BASE,
- .end= OMAP1_MBOX_BASE + OMAP1_MBOX_SIZE,
+ .start = OMAP16XX_MAILBOX_BASE,
+ .end= OMAP16XX_MAILBOX_BASE + OMAP1_MBOX_SIZE,
.flags = IORESOURCE_MEM,
},
{
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index caf889a..f3266dd 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -146,7 +146,6 @@ EXPORT_SYMBOL(mbox_dsp_info);
static int __devinit omap1_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
- int ret = 0;
if (pdev-num_resources != 2) {
dev_err(pdev-dev, invalid number of resources: %d\n,
@@ -160,7 +159,7 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
dev_err(pdev-dev, invalid mem resource\n);
return -ENODEV;
}
- mbox_base = res-start;
+ mbox_base = OMAP1_IO_ADDRESS(res-start);
/* DSP IRQ */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 281ab63..7263b9b 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -93,7 +93,7 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
mbox_ick_handle = clk_get(NULL, mailboxes_ick);
if (IS_ERR(mbox_ick_handle)) {
- printk(KERN_ERR Could not get mailboxes_ick: %d\n,
+ printk(KERN_ERR Could not get mailboxes_ick: %ld\n,
PTR_ERR(mbox_ick_handle));
return PTR_ERR(mbox_ick_handle);
}
@@ -279,8 +279,6 @@ static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.irqdisable = MAILBOX_IRQENABLE(0),
};
-
-
/* OMAP4 specific data structure. Use the cpu_is_omap4xxx()
to use this*/
static struct omap_mbox2_priv omap2_mbox_1_priv = {
@@ -336,7 +334,6 @@ struct omap_mbox mbox_2_info = {
};
EXPORT_SYMBOL(mbox_2_info);
-
#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
@@ -419,8 +416,10 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
#endif
return 0;
+#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
err_iva1:
omap_mbox_unregister(mbox_dsp_info);
+#endif
err_dsp:
iounmap(mbox_base);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 8d86b0b..822c377 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -82,7 +82,6 @@ static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t
msg)
return ret;
}
-
int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
{
@@ -108,7 +107,6 @@ static void mbox_tx_tasklet(unsigned long tx_data)
struct request_queue *q = mbox-txq-queue;
while (1) {
-
rq = blk_fetch_request(q);
if (!rq)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/15] omap: mailbox: reorganize structures
OMAP4 ones messed up the organization.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/mailbox.c | 68 +
1 files changed, 35 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 7263b9b..252e53b 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -262,6 +262,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
*/
/* FIXME: the following structs should be filled automatically by the user id
*/
+
/* DSP */
static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -279,8 +280,40 @@ static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.irqdisable = MAILBOX_IRQENABLE(0),
};
-/* OMAP4 specific data structure. Use the cpu_is_omap4xxx()
-to use this*/
+struct omap_mbox mbox_dsp_info = {
+ .name = dsp,
+ .ops= omap2_mbox_ops,
+ .priv = omap2_mbox_dsp_priv,
+};
+EXPORT_SYMBOL(mbox_dsp_info);
+
+#if defined(CONFIG_ARCH_OMAP2420)
+
+/* IVA */
+static struct omap_mbox2_priv omap2_mbox_iva_priv = {
+ .tx_fifo = {
+ .msg= MAILBOX_MESSAGE(2),
+ .fifo_stat = MAILBOX_FIFOSTATUS(2),
+ },
+ .rx_fifo = {
+ .msg= MAILBOX_MESSAGE(3),
+ .msg_stat = MAILBOX_MSGSTATUS(3),
+ },
+ .irqenable = MAILBOX_IRQENABLE(3),
+ .irqstatus = MAILBOX_IRQSTATUS(3),
+ .notfull_bit= MAILBOX_IRQ_NOTFULL(2),
+ .newmsg_bit = MAILBOX_IRQ_NEWMSG(3),
+ .irqdisable = MAILBOX_IRQENABLE(3),
+};
+
+static struct omap_mbox mbox_iva_info = {
+ .name = iva,
+ .ops= omap2_mbox_ops,
+ .priv = omap2_mbox_iva_priv,
+};
+#endif
+
+/* OMAP4 */
static struct omap_mbox2_priv omap2_mbox_1_priv = {
.tx_fifo = {
.msg= MAILBOX_MESSAGE(0),
@@ -304,13 +337,6 @@ struct omap_mbox mbox_1_info = {
};
EXPORT_SYMBOL(mbox_1_info);
-struct omap_mbox mbox_dsp_info = {
- .name = dsp,
- .ops= omap2_mbox_ops,
- .priv = omap2_mbox_dsp_priv,
-};
-EXPORT_SYMBOL(mbox_dsp_info);
-
static struct omap_mbox2_priv omap2_mbox_2_priv = {
.tx_fifo = {
.msg= MAILBOX_MESSAGE(3),
@@ -334,30 +360,6 @@ struct omap_mbox mbox_2_info = {
};
EXPORT_SYMBOL(mbox_2_info);
-#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
-static struct omap_mbox2_priv omap2_mbox_iva_priv = {
- .tx_fifo = {
- .msg= MAILBOX_MESSAGE(2),
- .fifo_stat = MAILBOX_FIFOSTATUS(2),
- },
- .rx_fifo = {
- .msg= MAILBOX_MESSAGE(3),
- .msg_stat = MAILBOX_MSGSTATUS(3),
- },
- .irqenable = MAILBOX_IRQENABLE(3),
- .irqstatus = MAILBOX_IRQSTATUS(3),
- .notfull_bit= MAILBOX_IRQ_NOTFULL(2),
- .newmsg_bit = MAILBOX_IRQ_NEWMSG(3),
- .irqdisable = MAILBOX_IRQENABLE(3),
-};
-
-static struct omap_mbox mbox_iva_info = {
- .name = iva,
- .ops= omap2_mbox_ops,
- .priv = omap2_mbox_iva_priv,
-};
-#endif
-
static int __devinit omap2_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/15] omap: mailbox: 2420 should be detected at run-time
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/mailbox.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 252e53b..6d17da8 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -431,7 +431,8 @@ err_dsp:
static int __devexit omap2_mbox_remove(struct platform_device *pdev)
{
#if defined(CONFIG_ARCH_OMAP2420)
- omap_mbox_unregister(mbox_iva_info);
+ if (cpu_is_omap2420())
+ omap_mbox_unregister(mbox_iva_info);
#endif
if (cpu_is_omap44xx()) {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/15] omap: mailbox: use correct config for omap1
CONFIG_OMAP_DSP is not in mainline, CONFIG_OMAP_MBOX_FWK is.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap1/devices.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 462b59c..da796f2 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -63,7 +63,7 @@ static void omap_init_rtc(void)
static inline void omap_init_rtc(void) {}
#endif
-#if defined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
+#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
#if defined(CONFIG_ARCH_OMAP15XX)
# define OMAP1_MBOX_SIZE 0x23
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/15] omap: mailbox: update omap1 probing
Based on omap2 code.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap1/mailbox.c | 25 +++--
1 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index f3266dd..9667f2f 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -146,12 +146,7 @@ EXPORT_SYMBOL(mbox_dsp_info);
static int __devinit omap1_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
-
- if (pdev-num_resources != 2) {
- dev_err(pdev-dev, invalid number of resources: %d\n,
- pdev-num_resources);
- return -ENODEV;
- }
+ int ret;
/* MBOX base */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -159,23 +154,33 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
dev_err(pdev-dev, invalid mem resource\n);
return -ENODEV;
}
- mbox_base = OMAP1_IO_ADDRESS(res-start);
+ mbox_base = ioremap(res-start, resource_size(res));
+ if (!mbox_base)
+ return -ENOMEM;
/* DSP IRQ */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!res)) {
dev_err(pdev-dev, invalid irq resource\n);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_out;
}
mbox_dsp_info.irq = res-start;
- return omap_mbox_register(pdev-dev, mbox_dsp_info);
+ ret = omap_mbox_register(pdev-dev, mbox_dsp_info);
+ if (ret)
+ goto err_out;
+ return 0;
+
+err_out:
+ iounmap(mbox_base);
+ return ret;
}
static int __devexit omap1_mbox_remove(struct platform_device *pdev)
{
omap_mbox_unregister(mbox_dsp_info);
-
+ iounmap(mbox_base);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/15] omap: mailbox: reorganize registering
This is a step forward to split the mbox registers.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap1/mailbox.c | 42 +
arch/arm/mach-omap2/mailbox.c | 99 +---
2 files changed, 65 insertions(+), 76 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 9667f2f..8b18313 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -29,6 +29,8 @@
static void __iomem *mbox_base;
+static struct omap_mbox **list;
+
struct omap_mbox1_fifo {
unsigned long cmd;
unsigned long data;
@@ -143,43 +145,45 @@ struct omap_mbox mbox_dsp_info = {
};
EXPORT_SYMBOL(mbox_dsp_info);
+struct omap_mbox *omap1_mboxes[] = { mbox_dsp_info, NULL };
+
static int __devinit omap1_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
int ret;
+ int i;
- /* MBOX base */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(!res)) {
- dev_err(pdev-dev, invalid mem resource\n);
- return -ENODEV;
- }
- mbox_base = ioremap(res-start, resource_size(res));
+ res = pdev-resource;
+
+ mbox_base = ioremap(res[0].start, resource_size(res[0]));
if (!mbox_base)
return -ENOMEM;
- /* DSP IRQ */
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (unlikely(!res)) {
- dev_err(pdev-dev, invalid irq resource\n);
- ret = -ENODEV;
- goto err_out;
- }
- mbox_dsp_info.irq = res-start;
+ list = omap1_mboxes;
- ret = omap_mbox_register(pdev-dev, mbox_dsp_info);
- if (ret)
- goto err_out;
+ list[0]-irq = res[1].start;
+
+ for (i = 0; list[i]; i++) {
+ ret = omap_mbox_register(pdev-dev, list[i]);
+ if (ret)
+ goto err_out;
+ }
return 0;
err_out:
+ while (i--)
+ omap_mbox_unregister(list[i]);
iounmap(mbox_base);
return ret;
}
static int __devexit omap1_mbox_remove(struct platform_device *pdev)
{
- omap_mbox_unregister(mbox_dsp_info);
+ int i;
+
+ for (i = 0; list[i]; i++)
+ omap_mbox_unregister(list[i]);
+
iounmap(mbox_base);
return 0;
}
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 6d17da8..0902965 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -53,6 +53,8 @@
static void __iomem *mbox_base;
+static struct omap_mbox **list;
+
struct omap_mbox2_fifo {
unsigned long msg;
unsigned long fifo_stat;
@@ -287,6 +289,8 @@ struct omap_mbox mbox_dsp_info = {
};
EXPORT_SYMBOL(mbox_dsp_info);
+struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
+
#if defined(CONFIG_ARCH_OMAP2420)
/* IVA */
@@ -311,6 +315,8 @@ static struct omap_mbox mbox_iva_info = {
.ops= omap2_mbox_ops,
.priv = omap2_mbox_iva_priv,
};
+
+struct omap_mbox *omap2_mboxes[] = { mbox_iva_info, mbox_dsp_info, NULL };
#endif
/* OMAP4 */
@@ -360,86 +366,65 @@ struct omap_mbox mbox_2_info = {
};
EXPORT_SYMBOL(mbox_2_info);
+struct omap_mbox *omap4_mboxes[] = { mbox_1_info, mbox_2_info, NULL };
+
static int __devinit omap2_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
int ret;
+ int i;
- /* MBOX base */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(!res)) {
- dev_err(pdev-dev, invalid mem resource\n);
- return -ENODEV;
- }
- mbox_base = ioremap(res-start, resource_size(res));
+ res = pdev-resource;
+
+ mbox_base = ioremap(res[0].start, resource_size(res[0]));
if (!mbox_base)
return -ENOMEM;
- /* DSP or IVA2 IRQ */
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (cpu_is_omap3430()) {
+ list = omap3_mboxes;
+
+ list[0]-irq = res[1].start;
+ }
+#if defined(CONFIG_ARCH_OMAP2420)
+ else if (cpu_is_omap2420()) {
+ list = omap2_mboxes;
- if (unlikely(!res)) {
- dev_err(pdev-dev, invalid irq resource\n);
- ret = -ENODEV;
- goto err_dsp;
+ list[0]-irq = res[1].start;
+ list[1]-irq = res[2].start;
}
- if (cpu_is_omap44xx()) {
- mbox_1_info.irq = res-start;
- ret = omap_mbox_register(pdev-dev, mbox_1_info);
- } else {
- mbox_dsp_info.irq = res-start;
- ret = omap_mbox_register(pdev-dev, mbox_dsp_info);
+#endif
+ else if (cpu_is_omap44xx()) {
+ list = omap4_mboxes;
+
+ list[0]-irq = res[1].start;
+ list[1]-irq = res[1].start;
}
- if
[PATCH 07/15] omap: mailbox: only compile for configured archs
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/mailbox.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0902965..103c670 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -265,6 +265,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
/* FIXME: the following structs should be filled automatically by the user id
*/
+#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP2420)
/* DSP */
static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -288,11 +289,13 @@ struct omap_mbox mbox_dsp_info = {
.priv = omap2_mbox_dsp_priv,
};
EXPORT_SYMBOL(mbox_dsp_info);
+#endif
+#if defined(CONFIG_ARCH_OMAP3430)
struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
+#endif
#if defined(CONFIG_ARCH_OMAP2420)
-
/* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
@@ -319,6 +322,7 @@ static struct omap_mbox mbox_iva_info = {
struct omap_mbox *omap2_mboxes[] = { mbox_iva_info, mbox_dsp_info, NULL };
#endif
+#if defined(CONFIG_ARCH_OMAP4)
/* OMAP4 */
static struct omap_mbox2_priv omap2_mbox_1_priv = {
.tx_fifo = {
@@ -367,6 +371,7 @@ struct omap_mbox mbox_2_info = {
EXPORT_SYMBOL(mbox_2_info);
struct omap_mbox *omap4_mboxes[] = { mbox_1_info, mbox_2_info, NULL };
+#endif
static int __devinit omap2_mbox_probe(struct platform_device *pdev)
{
@@ -380,11 +385,15 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (!mbox_base)
return -ENOMEM;
- if (cpu_is_omap3430()) {
+ if (false) {
+ }
+#if defined(CONFIG_ARCH_OMAP3430)
+ else if (cpu_is_omap3430()) {
list = omap3_mboxes;
list[0]-irq = res[1].start;
}
+#endif
#if defined(CONFIG_ARCH_OMAP2420)
else if (cpu_is_omap2420()) {
list = omap2_mboxes;
@@ -393,12 +402,14 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
list[1]-irq = res[2].start;
}
#endif
+#if defined(CONFIG_ARCH_OMAP4)
else if (cpu_is_omap44xx()) {
list = omap4_mboxes;
list[0]-irq = res[1].start;
list[1]-irq = res[1].start;
}
+#endif
else {
pr_err(%s: platform not supported\n, __func__);
return -ENODEV;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/15] omap: mailbox: reorganize omap platform_device
Makes more sense to register in the mach file, plus it will allow more
functionality later on.
Also, this probably enables multi-omap for real.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap1/devices.c | 38
arch/arm/mach-omap1/mailbox.c | 57
arch/arm/mach-omap2/devices.c | 74 ---
arch/arm/mach-omap2/mailbox.c | 97 +++--
4 files changed, 150 insertions(+), 116 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index da796f2..093dd13 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -63,43 +63,6 @@ static void omap_init_rtc(void)
static inline void omap_init_rtc(void) {}
#endif
-#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-
-#if defined(CONFIG_ARCH_OMAP15XX)
-# define OMAP1_MBOX_SIZE 0x23
-# define INT_DSP_MAILBOX1 INT_1510_DSP_MAILBOX1
-#elif defined(CONFIG_ARCH_OMAP16XX)
-# define OMAP1_MBOX_SIZE 0x2f
-# define INT_DSP_MAILBOX1 INT_1610_DSP_MAILBOX1
-#endif
-
-static struct resource mbox_resources[] = {
- {
- .start = OMAP16XX_MAILBOX_BASE,
- .end= OMAP16XX_MAILBOX_BASE + OMAP1_MBOX_SIZE,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_DSP_MAILBOX1,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device mbox_device = {
- .name = omap1-mailbox,
- .id = -1,
- .num_resources = ARRAY_SIZE(mbox_resources),
- .resource = mbox_resources,
-};
-
-static inline void omap_init_mbox(void)
-{
- platform_device_register(mbox_device);
-}
-#else
-static inline void omap_init_mbox(void) { }
-#endif
-
/*-*/
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
@@ -293,7 +256,6 @@ static int __init omap1_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
- omap_init_mbox();
omap_init_rtc();
omap_init_spi100k();
omap_init_sti();
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 8b18313..e28b226 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -147,6 +147,20 @@ EXPORT_SYMBOL(mbox_dsp_info);
struct omap_mbox *omap1_mboxes[] = { mbox_dsp_info, NULL };
+#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
+static struct resource omap1_mbox_resources[] = {
+ {
+ .start = OMAP16XX_MAILBOX_BASE,
+ .end= OMAP16XX_MAILBOX_BASE, /* to be updated */
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = 10,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+#endif
+
static int __devinit omap1_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
@@ -198,7 +212,50 @@ static struct platform_driver omap1_mbox_driver = {
static int __init omap1_mbox_init(void)
{
+ int err;
+ struct platform_device *pdev;
+ struct resource *res;
+ unsigned num;
+
+ if (false) {
+ }
+#if defined(CONFIG_ARCH_OMAP15XX)
+ else if (cpu_is_omap15xx()) {
+ res = omap1_mbox_resources;
+ num = ARRAY_SIZE(omap1_mbox_resources);
+ res[1].end += 0x23;
+ }
+#endif
+#if defined(CONFIG_ARCH_OMAP16XX)
+ else if (cpu_is_omap16xx()) {
+ res = omap1_mbox_resources;
+ num = ARRAY_SIZE(omap1_mbox_resources);
+ res[1].end += 0x2f;
+ }
+#endif
+ else {
+ pr_err(%s: platform not supported\n, __func__);
+ return -ENODEV;
+ }
+
+ pdev = platform_device_alloc(omap1-mailbox, -1);
+ if (!pdev) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ err = platform_device_add_resources(pdev, res, num);
+ if (err)
+ goto err_out;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto err_out;
+
return platform_driver_register(omap1_mbox_driver);
+
+err_out:
+ return err;
}
static void __exit omap1_mbox_exit(void)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 18ad931..bc7ac38 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -136,79 +136,6 @@ static inline void omap_init_camera(void)
}
#endif
-#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-
-#define MBOX_REG_SIZE 0x120
-
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap_mbox_resources[] = {
- {
- .start = OMAP24XX_MAILBOX_BASE,
- .end
[PATCH 09/15] omap: mailbox: move more stuff to omap_mbox_init()
Will be needed to split the platform_driver.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap1/mailbox.c | 23 ++
arch/arm/mach-omap2/mailbox.c | 50 ++--
2 files changed, 31 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index e28b226..d57fb5d 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -169,14 +169,6 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
res = pdev-resource;
- mbox_base = ioremap(res[0].start, resource_size(res[0]));
- if (!mbox_base)
- return -ENOMEM;
-
- list = omap1_mboxes;
-
- list[0]-irq = res[1].start;
-
for (i = 0; list[i]; i++) {
ret = omap_mbox_register(pdev-dev, list[i]);
if (ret)
@@ -187,7 +179,6 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
err_out:
while (i--)
omap_mbox_unregister(list[i]);
- iounmap(mbox_base);
return ret;
}
@@ -198,7 +189,6 @@ static int __devexit omap1_mbox_remove(struct
platform_device *pdev)
for (i = 0; list[i]; i++)
omap_mbox_unregister(list[i]);
- iounmap(mbox_base);
return 0;
}
@@ -223,14 +213,20 @@ static int __init omap1_mbox_init(void)
else if (cpu_is_omap15xx()) {
res = omap1_mbox_resources;
num = ARRAY_SIZE(omap1_mbox_resources);
+ list = omap1_mboxes;
+
res[1].end += 0x23;
+ list[0]-irq = res[1].start;
}
#endif
#if defined(CONFIG_ARCH_OMAP16XX)
else if (cpu_is_omap16xx()) {
res = omap1_mbox_resources;
num = ARRAY_SIZE(omap1_mbox_resources);
+ list = omap1_mboxes;
+
res[1].end += 0x2f;
+ list[0]-irq = res[1].start;
}
#endif
else {
@@ -252,6 +248,12 @@ static int __init omap1_mbox_init(void)
if (err)
goto err_out;
+ mbox_base = ioremap(res[0].start, resource_size(res[0]));
+ if (!mbox_base) {
+ platform_device_put(pdev);
+ return -ENOMEM;
+ }
+
return platform_driver_register(omap1_mbox_driver);
err_out:
@@ -261,6 +263,7 @@ err_out:
static void __exit omap1_mbox_exit(void)
{
platform_driver_unregister(omap1_mbox_driver);
+ iounmap(mbox_base);
}
module_init(omap1_mbox_init);
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 31a0659..cea18bc 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -427,36 +427,6 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
res = pdev-resource;
- mbox_base = ioremap(res[0].start, resource_size(res[0]));
- if (!mbox_base)
- return -ENOMEM;
-
- if (false) {
- }
-#if defined(CONFIG_ARCH_OMAP3430)
- else if (cpu_is_omap3430()) {
- list = omap3_mboxes;
-
- list[0]-irq = res[1].start;
- }
-#endif
-#if defined(CONFIG_ARCH_OMAP2420)
- else if (cpu_is_omap2420()) {
- list = omap2_mboxes;
-
- list[0]-irq = res[1].start;
- list[1]-irq = res[2].start;
- }
-#endif
-#if defined(CONFIG_ARCH_OMAP4)
- else if (cpu_is_omap44xx()) {
- list = omap4_mboxes;
-
- list[0]-irq = res[1].start;
- list[1]-irq = res[1].start;
- }
-#endif
-
for (i = 0; list[i]; i++) {
ret = omap_mbox_register(pdev-dev, list[i]);
if (ret)
@@ -467,7 +437,6 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
err_out:
while (i--)
omap_mbox_unregister(list[i]);
- iounmap(mbox_base);
return ret;
}
@@ -478,7 +447,6 @@ static int __devexit omap2_mbox_remove(struct
platform_device *pdev)
for (i = 0; list[i]; i++)
omap_mbox_unregister(list[i]);
- iounmap(mbox_base);
return 0;
}
@@ -503,18 +471,29 @@ static int __init omap2_mbox_init(void)
else if (cpu_is_omap3430()) {
res = omap3_mbox_resources;
num = ARRAY_SIZE(omap3_mbox_resources);
+ list = omap3_mboxes;
+
+ list[0]-irq = res[1].start;
}
#endif
#if defined(CONFIG_ARCH_OMAP2420)
else if (cpu_is_omap2420()) {
res = omap2_mbox_resources;
num = ARRAY_SIZE(omap2_mbox_resources);
+ list = omap2_mboxes;
+
+ list[0]-irq = res[1].start;
+ list[1]-irq = res[2].start;
}
#endif
#if defined(CONFIG_ARCH_OMAP4)
else if (cpu_is_omap44xx()) {
res = omap4_mbox_resources;
num = ARRAY_SIZE(omap4_mbox_resources);
+
[PATCH 10/15] omap: mailbox: trivial sync between omap1 and 2
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap1/mailbox.c |2 +-
arch/arm/mach-omap2/mailbox.c |6 ++
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index d57fb5d..64c1dc2 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -1,5 +1,5 @@
/*
- * Mailbox reservation modules for DSP
+ * Mailbox reservation modules for OMAP1
*
* Copyright (C) 2006-2009 Nokia Corporation
* Written by: Hiroshi DOYU hiroshi.d...@nokia.com
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index cea18bc..941ee30 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -18,8 +18,6 @@
#include plat/mailbox.h
#include mach/irqs.h
-#define DRV_NAME omap2-mailbox
-
#define MAILBOX_REVISION 0x000
#define MAILBOX_SYSCONFIG 0x010
#define MAILBOX_SYSSTATUS 0x014
@@ -454,7 +452,7 @@ static struct platform_driver omap2_mbox_driver = {
.probe = omap2_mbox_probe,
.remove = __devexit_p(omap2_mbox_remove),
.driver = {
- .name = DRV_NAME,
+ .name = omap2-mailbox,
},
};
@@ -539,4 +537,4 @@ module_exit(omap2_mbox_exit);
MODULE_LICENSE(GPL v2);
MODULE_DESCRIPTION(omap mailbox: omap2/3/4 architecture specific functions);
MODULE_AUTHOR(Hiroshi DOYU hiroshi.d...@nokia.com, Paul Mundt);
-MODULE_ALIAS(platform:DRV_NAME);
+MODULE_ALIAS(platform:omap2-mailbox);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/15] omap: mailbox: split platform driver
This will allow the current 'mailbox_mach' to be built-in.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap1/mailbox.c | 50 +
arch/arm/mach-omap2/mailbox.c | 50 +
arch/arm/plat-omap/include/plat/mailbox.h |4 ++
arch/arm/plat-omap/mailbox.c | 45 +-
4 files changed, 64 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 64c1dc2..036e159 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -161,51 +161,13 @@ static struct resource omap1_mbox_resources[] = {
};
#endif
-static int __devinit omap1_mbox_probe(struct platform_device *pdev)
-{
- struct resource *res;
- int ret;
- int i;
-
- res = pdev-resource;
-
- for (i = 0; list[i]; i++) {
- ret = omap_mbox_register(pdev-dev, list[i]);
- if (ret)
- goto err_out;
- }
- return 0;
-
-err_out:
- while (i--)
- omap_mbox_unregister(list[i]);
- return ret;
-}
-
-static int __devexit omap1_mbox_remove(struct platform_device *pdev)
-{
- int i;
-
- for (i = 0; list[i]; i++)
- omap_mbox_unregister(list[i]);
-
- return 0;
-}
-
-static struct platform_driver omap1_mbox_driver = {
- .probe = omap1_mbox_probe,
- .remove = __devexit_p(omap1_mbox_remove),
- .driver = {
- .name = omap1-mailbox,
- },
-};
-
static int __init omap1_mbox_init(void)
{
int err;
struct platform_device *pdev;
struct resource *res;
unsigned num;
+ struct omap_mbox_platform_data pdata;
if (false) {
}
@@ -234,7 +196,7 @@ static int __init omap1_mbox_init(void)
return -ENODEV;
}
- pdev = platform_device_alloc(omap1-mailbox, -1);
+ pdev = platform_device_alloc(omap-mailbox, -1);
if (!pdev) {
err = -ENOMEM;
goto err_out;
@@ -244,6 +206,11 @@ static int __init omap1_mbox_init(void)
if (err)
goto err_out;
+ pdata.list = list;
+ err = platform_device_add_data(pdev, pdata, sizeof(pdata));
+ if (err)
+ goto err_out;
+
err = platform_device_add(pdev);
if (err)
goto err_out;
@@ -254,7 +221,7 @@ static int __init omap1_mbox_init(void)
return -ENOMEM;
}
- return platform_driver_register(omap1_mbox_driver);
+ return 0;
err_out:
return err;
@@ -262,7 +229,6 @@ err_out:
static void __exit omap1_mbox_exit(void)
{
- platform_driver_unregister(omap1_mbox_driver);
iounmap(mbox_base);
}
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 941ee30..7abd159 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -417,51 +417,13 @@ static struct resource omap4_mbox_resources[] = {
};
#endif
-static int __devinit omap2_mbox_probe(struct platform_device *pdev)
-{
- struct resource *res;
- int ret;
- int i;
-
- res = pdev-resource;
-
- for (i = 0; list[i]; i++) {
- ret = omap_mbox_register(pdev-dev, list[i]);
- if (ret)
- goto err_out;
- }
- return 0;
-
-err_out:
- while (i--)
- omap_mbox_unregister(list[i]);
- return ret;
-}
-
-static int __devexit omap2_mbox_remove(struct platform_device *pdev)
-{
- int i;
-
- for (i = 0; list[i]; i++)
- omap_mbox_unregister(list[i]);
-
- return 0;
-}
-
-static struct platform_driver omap2_mbox_driver = {
- .probe = omap2_mbox_probe,
- .remove = __devexit_p(omap2_mbox_remove),
- .driver = {
- .name = omap2-mailbox,
- },
-};
-
static int __init omap2_mbox_init(void)
{
int err;
struct platform_device *pdev;
struct resource *res;
unsigned num;
+ struct omap_mbox_platform_data pdata;
if (false) {
}
@@ -499,7 +461,7 @@ static int __init omap2_mbox_init(void)
return -ENODEV;
}
- pdev = platform_device_alloc(omap2-mailbox, -1);
+ pdev = platform_device_alloc(omap-mailbox, -1);
if (!pdev) {
err = -ENOMEM;
goto err_out;
@@ -509,6 +471,11 @@ static int __init omap2_mbox_init(void)
if (err)
goto err_out;
+ pdata.list = list;
+ err = platform_device_add_data(pdev, pdata, sizeof(pdata));
+ if (err)
+ goto err_out;
+
err = platform_device_add(pdev);
if (err)
goto err_out;
@@ -519,7 +486,7 @@ static int __init omap2_mbox_init(void)
return -ENOMEM;
}
- return
[PATCH 15/15] omap: mailbox: mark some resources as __initdata
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap1/mailbox.c |2 +-
arch/arm/mach-omap2/mailbox.c |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index b01d3c3..74d2677 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -144,7 +144,7 @@ struct omap_mbox mbox_dsp_info = {
struct omap_mbox *omap1_mboxes[] = { mbox_dsp_info, NULL };
#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
-static struct resource omap1_mbox_resources[] = {
+static struct resource __initdata omap1_mbox_resources[] = {
{
.start = OMAP16XX_MAILBOX_BASE,
.end= OMAP16XX_MAILBOX_BASE, /* to be updated */
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index b0d7740..a2fa784 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -368,7 +368,7 @@ struct omap_mbox *omap4_mboxes[] = { mbox_1_info,
mbox_2_info, NULL };
#endif
#ifdef CONFIG_ARCH_OMAP2420
-static struct resource omap2_mbox_resources[] = {
+static struct resource __initdata omap2_mbox_resources[] = {
{
.start = OMAP24XX_MAILBOX_BASE,
.end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
@@ -386,7 +386,7 @@ static struct resource omap2_mbox_resources[] = {
#endif
#ifdef CONFIG_ARCH_OMAP3430
-static struct resource omap3_mbox_resources[] = {
+static struct resource __initdata omap3_mbox_resources[] = {
{
.start = OMAP34XX_MAILBOX_BASE,
.end= OMAP34XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
@@ -400,7 +400,7 @@ static struct resource omap3_mbox_resources[] = {
#endif
#ifdef CONFIG_ARCH_OMAP4
-static struct resource omap4_mbox_resources[] = {
+static struct resource __initdata omap4_mbox_resources[] = {
{
.start = OMAP44XX_MAILBOX_BASE,
.end= OMAP44XX_MAILBOX_BASE + OMAP4_MBOX_REG_SIZE -
1,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault debugging trace
-Original Message-
From: Menon, Nishanth
Sent: Thursday, May 13, 2010 10:49 AM
To: Ramos Falcon, Ernesto
Cc: linux-omap@vger.kernel.org; Ameya Palande; Contreras Felipe (Nokia-
D/Helsinki)
Subject: Re: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault
debugging trace
Ramos Falcon, Ernesto had written, on 05/13/2010 10:40 AM, the following:
Resending this patch rebased to the last changes included in dspbridge.
---
Some execution info is missing at the beginning of the
trace buffer printout. This fix is to include this information
according to the buffer contents description and
also couple of cosmetic changes to make the traces more
readable.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/core/io_sm.c | 44 +++--
-
1 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/dsp/bridge/core/io_sm.c
b/drivers/dsp/bridge/core/io_sm.c
index d6c1a98..d11bd9f 100644
--- a/drivers/dsp/bridge/core/io_sm.c
+++ b/drivers/dsp/bridge/core/io_sm.c
@@ -1949,9 +1949,9 @@ dsp_status print_dsp_trace_buffer(struct
bridge_dev_context *hbridge_context)
if (DSP_FAILED(status))
goto func_end;
/* Pack and do newline conversion */
-pr_info(%s: DSP Trace Buffer Begin:\n
+pr_info(DSP Trace Buffer Begin:\n
===\n%s\n,
-__func__, psz_buf);
+psz_buf);
/* convert to offset */
@@ -2058,6 +2058,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
u32 size;
} mmu_fault_dbg_info;
u32 *buffer;
+u32 *buffer_beg;
u32 *buffer_end;
u32 exc_type;
u32 i;
@@ -2067,6 +2068,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
const char *dsp_regs[] = {EFR, IERR, ITSR, NTSR,
IRP, NRP, AMR, SSR,
ILC, RILC, IER, CSR};
+const char *exec_ctxt[] = {Task, SWI, HWI, Unknown};
struct bridge_drv_interface *intf_fxns;
struct dev_object *dev_object = bridge_context-hdev_obj;
@@ -2136,6 +2138,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
total_size = MAX_MMU_DBGBUFF;
buffer = kzalloc(total_size, GFP_ATOMIC);
+buffer_beg = buffer;
buffer_end = buffer + total_size / 4;
if (!buffer) {
@@ -2155,7 +2158,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
goto func_end;
}
-pr_err(Aproximate Crash Position:\n);
+pr_err(\nAproximate Crash Position:\n);
pr_err(--\n);
exc_type = buffer[3];
@@ -2171,7 +2174,27 @@ dsp_status dump_dsp_stack(struct
bridge_dev_context *bridge_context)
else
pr_err(0x%-8x [Unable to match to a symbol.]\n, i);
-pr_err(Execution Info:\n);
+buffer += 4;
+
+pr_err(\nExecution Info:\n);
+pr_err(---\n);
+
+if (*buffer ARRAY_SIZE(exec_ctxt)) {
+pr_err(Execution context \t%s\n,
+exec_ctxt[*buffer++]);
+} else {
+pr_err(Execution context corrupt\n);
+kfree(buffer_beg);
+return -EFAULT;
+}
+pr_err(Task Handle\t\t0x%x\n, *buffer++);
+pr_err(Stack Pointer\t\t0x%x\n, *buffer++);
+pr_err(Stack Top\t\t0x%x\n, *buffer++);
+pr_err(Stack Bottom\t\t0x%x\n, *buffer++);
+pr_err(Stack Size\t\t0x%x\n, *buffer++);
+pr_err(Stack Size In Use\t0x%x\n, *buffer++);
+
How about casting buffer to a structure and using it?
the use of buffer++ etc is a nightmare as can be seen here..
I don't see the need to use a structure for this set of data if anyway I need
to use buffer++ for the rest of the buffer data. Furthermore, if I declare a
structure I need to initialize it using buffer as a reference.
I don't think is such a nightmare.
+pr_err(\nCPU Registers\n);
pr_err(---\n);
btw, linux allows you to use string in a single pr_err.. e.g.
pr_err(\n CPU Registers\n
\n);
it is a bit easier on the system without going thru two function call
overhead
OK. I'll change that.
for (i = 0; i 32; i++) {
@@ -2205,16 +2228,21 @@ dsp_status dump_dsp_stack(struct
bridge_dev_context *bridge_context)
if (i == 4 || i == 6 || i == 8)
pr_err(B%d 0x%-8x [Function Argument %d]\n,
i, *buffer++, i-2);
-else if (i == 15)
+else if (i == 14)
RE: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault debugging trace
Hi,
-Original Message-
From: Kanigeri, Hari
Sent: Thursday, May 13, 2010 10:55 AM
To: Ramos Falcon, Ernesto; linux-omap@vger.kernel.org
Cc: Ameya Palande; Contreras Felipe (Nokia-D/Helsinki)
Subject: RE: [PATCHv2] DSPBRIDGE: Include missing info in MMU Fault
debugging trace
Ernesto
@@ -2136,6 +2138,7 @@ dsp_status dump_dsp_stack(struct bridge_dev_context
*bridge_context)
total_size = MAX_MMU_DBGBUFF;
buffer = kzalloc(total_size, GFP_ATOMIC);
+buffer_beg = buffer;
buffer_end = buffer + total_size / 4;
if (!buffer) {
-- Shouldn't this check be present before the above 2 statements ?
I think in this case does not affect those two assignments could be avoid it,
so OK.
for (i = 0; buffer buffer_end; i++, buffer++) {
if ((*buffer 0x0100) (node_find_addr(node_mgr,
-- Is 0x0100 MAX_MMU_DBGBUFF ?
OK, I'll change.
Thank you,
Best regards,
Hari
--
To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 10:33 AM, Daniel Walker dwal...@fifo99.com wrote: On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote: On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote: Figuring out a different way to do this should not limit Android at all, since Google can do what other Linux distributions do and continue to patch opportunistic suspend/suspend-block calls into their kernels as needed to ship devices, while contributing towards a different solution to the problem. I basically agree, except that despite having a year to do so none of us have come up with a different way that would actually work. Google have done this work. Who's going to prove that there is actually a different way to do this? We all feel the pain of inelegance right? I think it's clear that this system will not last (but there's no other immediate option) .. That doesn't mean we should reject it, but we need to be clear that this system will get replaced. So we should format the patches appropriately. To me the userspace aspect is a permanent change .. If we could drop that (or put it into debugfs) then it would make this a lot easy to accept as a stepping stone. I'm in agreement on the first half of this -- from the Google/Android point of view, if we can someday accomplish everything we need with some different facility, we'll happily shift over to that. That seems like a normal operating mode for mainline -- new solutions arise, drivers are migrated to those new solutions, old solutions fall to the wayside. We fully expect that the world will change over time and one of our largest goals with trying to get work upstream is to reduce the pain of those changes for everyone, while trying to get to you can build a kernel out of the box from mainline that Just Works with an android userspace. I'm not sure this necessitates using only debugfs for the userspace interface. A userspace interface is necessary to accomplish what we're trying to do here, otherwise we have only half a solution, and our hope is that it'd be a stable interface (as userspace interfaces are supposed to be) for as long as its needed. I could totally imagine the userspace interface eventually becoming a no-op or punching through to some other facility, depending on how this problem is solved long-term in the ideal post-suspend-block future. Brian -- To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 11:17 -0700, Brian Swetland wrote: I'm not sure this necessitates using only debugfs for the userspace interface. A userspace interface is necessary to accomplish what we're trying to do here, otherwise we have only half a solution, and our hope is that it'd be a stable interface (as userspace interfaces are supposed to be) for as long as its needed. I could totally imagine the userspace interface eventually becoming a no-op or punching through to some other facility, depending on how this problem is solved long-term in the ideal post-suspend-block future. The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Daniel -- To unsubscribe from this list: send the line unsubscribe 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] DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT
On Thu, May 13, 2010 at 8:29 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: First of all, what is the DSP supposed to do with that memory? Do we really need to call hw_mmu_tlb_add at all? Once DSP MMUfault happens iva mmu module prevents DSP continue executing until mmu module is able get some physical address for the virtual address that the dsp wanted to access. Once mmu fault interrupt is acked the mmu module tries to translate the virtual address again and if it gets the physical address DSP continue executing. This is if we want the DSP to continue executing, which all the code assumes we don't. If we wanted to do that, then we would need to know how to get the data that the DSP code was trying to access, but we don't. We always provide the data beforehand, and if the DSP code tries to access something else, there's nothing else to do. So in order to DSP can dumps its stack we need to map some physical address to that virtual address, so that mmu release DSP and it can dumps the stack. But the DSP is not dumping the stack there, from what I can see bridge_brd_read() is used to read DSP internal memory. You said yourself that you could pass a totally dummy address like 0, and the stack will still be printed. Therefore we allocate some dummy buffer of one 4K page and get the physical address of that buffer and use that physical address to fill the tbl on the mmu module using hw_mmu_tlb_add function. I think that's wrong. We should not give the DSP hopes that it will be able to read data from that fault address... it's over. However the address returned by kmalloc is not page aling, that's means this mpu virtual address has some offset, for examples in the log that were send the dummy address had an offset of 0x080 and the DSP side virtual memory had an offset of 0x040. base on the offset of the MPU side and as we allocate one page that means we can access from 0x080 - 0xfff of the first page and from 0x000 - 0x080 if the second page, but we always allocate the first page to the DSP side, then DSP access to the address it wanted to access and now there is no mmufault but it is accessing (actually writing because reading not cause corruption) to that page but with a offset of 0x040 causing the corruption. Using get_user_pages fixes that case because as it returns address page aligned the DSP side can access from 0x000 - 0xfff of that page. You mean __get_free_pages? However this is not the right solution because lets suppose if DSP side virtual address offset is 0xfff. So we map a page and DSP can access that page from 0x000 - 0xfff, however is the DSP is able to continue executing it will reach the following page and maybe that page is already mapped but it only can access from an specific offset like for example 0x100, in this ca DSP will still corrupt from 0x000 to 0x0ff of the next page. From what I understand it's impossible for the DSP to access memory that wasn't mapped. So if we map only that page, when the DSP tries to write to 0x100, another MMU fault will happen. If I'm understanding things correctly, then we shouldn't map the faulty address again (through hw_mmu_tlb_add), and we shouldn't clear the interrupt either (HW_MMU_TRANSLATION_FAULT). (I haven't tested this yet). Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote: The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. -- Matthew Garrett | mj...@srcf.ucam.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 2/3] omap3 nand: cleanup for not to use GPMC virtual address
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: 2010-05-13 21:11
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org;
sako...@gmail.com; m...@compulab.co.il; artem.bityuts...@nokia.com
Subject: Re: [PATCH 2/3] omap3 nand: cleanup for not to use GPMC virtual
address
* Sukumar Ghorai s-gho...@ti.com [100512 02:43]:
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -64,16 +64,32 @@ static void __iomem *gpmc_base;
static struct clk *gpmc_l3_clk;
-static void gpmc_write_reg(int idx, u32 val)
+void gpmc_write_reg(int idx, u32 val)
{
__raw_writel(val, gpmc_base + idx);
}
-static u32 gpmc_read_reg(int idx)
+u32 gpmc_read_reg(int idx)
{
return __raw_readl(gpmc_base + idx);
}
+void gpmc_cs_write_byte(int cs, int idx, u32 val)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
+ __raw_writeb(val, reg_addr);
+}
+
+u8 gpmc_cs_read_byte(int cs, int idx)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
+ return __raw_readb(reg_addr);
+}
+
This will not improve the situation unfortunately.
We for sure don't want to export functions to mess
with the GPMC registers all over the place.
@@ -432,15 +448,6 @@ void gpmc_prefetch_reset(void)
}
EXPORT_SYMBOL(gpmc_prefetch_reset);
-/**
- * gpmc_prefetch_status - reads prefetch status of engine
- */
-int gpmc_prefetch_status(void)
-{
- return gpmc_read_reg(GPMC_PREFETCH_STATUS);
-}
-EXPORT_SYMBOL(gpmc_prefetch_status);
-
And we don't want to remove GPMC functions like this,
instead we need to implement more functions like this
for the platform init code to use.
[Ghorai]
1. NAND IO address needed by core NAND driver. So we can't move that access to
GMPC.
2. And is it ok if we add functions as below and all need to be as
EXPORT_SYMBOL too?
get_gpmc_status()
get_gpmc_irq_status()
set_gpmc_irq_status()
set_gpmc_irq_enable()
get_gpmc_config
set_gpmc_config
get_gpmc_status()
get_gpmc_prefetch_config()
gpmc_prefetch_status
set_gpmc_ecc_config
set_gpmc_ecc_contol
set_gpmc_ecc_size
get_gpmc_ecc_result
Regards,
Sukumar
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] MMC: OMAP HS-MMC: convert to dev_pm_ops
On Tue, 11 May 2010 14:57:16 -0700, Kevin Hilman khil...@deeprootsystems.com wrote: Note that dev_pm_ops version of the suspend hook no longer takes a 'state' argument. However, the MMC core function mmc_suspend_host() still takes a 'state' argument, but it is unused, so a dummy state variable was created to pass to the MMC core. Hmm.. instead of passing this dummy state argument why don't we just remove the argument from mmc_suspend_host()? Like you said, it's unused, so I don't see a reason to keep it around? -- To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote: The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. Daniel -- To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. -- Matthew Garrett | mj...@srcf.ucam.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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
* Alan Stern st...@rowland.harvard.edu [100513 07:11]: On Wed, 12 May 2010, Paul Walmsley wrote: Hello, Some general comments on the suspend blockers/wakelock/opportunistic suspend v6 patch series, posted here: https://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025146.html The comments below are somewhat telegraphic in the interests of readability - more specific comments to follow in later E-mails. I am indebted to those of us who discussed these issues at LPC last year and ELC this year for several stimulating discussions. There are several general problems with the design of opportunistic suspend and suspend-blocks. 1. The opportunistic suspend code bypasses existing Linux kernel code, such as timers and the scheduler, that indicates when code needs to run, and when the system is idle. Whoa! That's not my understanding at all. As I see it, opportunistic suspend doesn't bypass any code that isn't already bypassed by the existing suspend code. Users can do echo mem /sys/power/state whenever they want, without regard to kernel timers and the scheduler (other than the fact that the user's thread must be running in order to carry out the write, of course). The difference between echo mem /sys/power/state and suspend blocks is that with suspend blocks the system keeps running. And that's why it should be handled by runtime power management instead. The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. I believe categorizing the apps should be instead done with some timer flags or cgroups instead. Cheers, 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote: The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. I believe categorizing the apps should be instead done with some timer flags or cgroups instead. I agree, but we have no mechanism for implementing that in a race-free way. We don't even have a realistical proposal for what that mechanism would look like. Should we refuse bread today for the promise of cake tomorrow? -- Matthew Garrett | mj...@srcf.ucam.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] mmc-omap: Add support for 16-bit and 32-bit registers
Hi Andrew,
* Cory Maccarrone darkstar6...@gmail.com [100307 09:44]:
From: Marek Belisko marek.beli...@open-nandra.com
The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
a modification of the register addresses in the mmc-omap driver. To resolve
this, a bit shift is performed on base register addresses, either by 1 or 2
bits depending on the CPU in use. This yields the correct registers for
each CPU.
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
Can you please queue this patch too? Ben's comments in this thread
were for the i2c-omap, not for this MMC patch. We've had this patch
in the omap tree for testing for quite a while now.
The patch is also available in at:
https://patchwork.kernel.org/patch/83971/
with the direct link to the mbox being:
https://patchwork.kernel.org/patch/83971/mbox/
Regards,
Tony
drivers/mmc/host/omap.c | 62
+--
1 files changed, 33 insertions(+), 29 deletions(-)
This is a resubmit of a patch I sent in several months ago. Tony Lindgren
merged
this into linux-omap's master and testing branches but has stated that he
will not
merge it further as linux-mmc needs to approve this. There hasn't been any
comments
raised on either of the linux-omap or linux-mmc mailing lists about problems.
Due to
the unique nature of the omap7xx platform, this patch is required for MMC
card access.
Is there any chance this can be included into the next -rc cycle, as it is a
fix for
devices that have 16-bit registers?
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index c6d7e8e..53362c4 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -38,30 +38,30 @@
#include plat/fpga.h
#define OMAP_MMC_REG_CMD0x00
-#define OMAP_MMC_REG_ARGL 0x04
-#define OMAP_MMC_REG_ARGH 0x08
-#define OMAP_MMC_REG_CON0x0c
-#define OMAP_MMC_REG_STAT 0x10
-#define OMAP_MMC_REG_IE 0x14
-#define OMAP_MMC_REG_CTO0x18
-#define OMAP_MMC_REG_DTO0x1c
-#define OMAP_MMC_REG_DATA 0x20
-#define OMAP_MMC_REG_BLEN 0x24
-#define OMAP_MMC_REG_NBLK 0x28
-#define OMAP_MMC_REG_BUF0x2c
-#define OMAP_MMC_REG_SDIO0x34
-#define OMAP_MMC_REG_REV0x3c
-#define OMAP_MMC_REG_RSP0 0x40
-#define OMAP_MMC_REG_RSP1 0x44
-#define OMAP_MMC_REG_RSP2 0x48
-#define OMAP_MMC_REG_RSP3 0x4c
-#define OMAP_MMC_REG_RSP4 0x50
-#define OMAP_MMC_REG_RSP5 0x54
-#define OMAP_MMC_REG_RSP6 0x58
-#define OMAP_MMC_REG_RSP7 0x5c
-#define OMAP_MMC_REG_IOSR 0x60
-#define OMAP_MMC_REG_SYSC 0x64
-#define OMAP_MMC_REG_SYSS 0x68
+#define OMAP_MMC_REG_ARGL 0x01
+#define OMAP_MMC_REG_ARGH 0x02
+#define OMAP_MMC_REG_CON0x03
+#define OMAP_MMC_REG_STAT 0x04
+#define OMAP_MMC_REG_IE 0x05
+#define OMAP_MMC_REG_CTO0x06
+#define OMAP_MMC_REG_DTO0x07
+#define OMAP_MMC_REG_DATA 0x08
+#define OMAP_MMC_REG_BLEN 0x09
+#define OMAP_MMC_REG_NBLK 0x0a
+#define OMAP_MMC_REG_BUF0x0b
+#define OMAP_MMC_REG_SDIO 0x0d
+#define OMAP_MMC_REG_REV0x0f
+#define OMAP_MMC_REG_RSP0 0x10
+#define OMAP_MMC_REG_RSP1 0x11
+#define OMAP_MMC_REG_RSP2 0x12
+#define OMAP_MMC_REG_RSP3 0x13
+#define OMAP_MMC_REG_RSP4 0x14
+#define OMAP_MMC_REG_RSP5 0x15
+#define OMAP_MMC_REG_RSP6 0x16
+#define OMAP_MMC_REG_RSP7 0x17
+#define OMAP_MMC_REG_IOSR 0x18
+#define OMAP_MMC_REG_SYSC 0x19
+#define OMAP_MMC_REG_SYSS 0x1a
#define OMAP_MMC_STAT_CARD_ERR (1 14)
#define OMAP_MMC_STAT_CARD_IRQ (1 13)
@@ -77,8 +77,9 @@
#define OMAP_MMC_STAT_CARD_BUSY (1 2)
#define OMAP_MMC_STAT_END_OF_CMD(1 0)
-#define OMAP_MMC_READ(host, reg) __raw_readw((host)-virt_base +
OMAP_MMC_REG_##reg)
-#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val),
(host)-virt_base + OMAP_MMC_REG_##reg)
+#define OMAP_MMC_REG(host, reg) (OMAP_MMC_REG_##reg
(host)-reg_shift)
+#define OMAP_MMC_READ(host, reg) __raw_readw((host)-virt_base +
OMAP_MMC_REG(host, reg))
+#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val),
(host)-virt_base + OMAP_MMC_REG(host, reg))
/*
* Command types
@@ -132,6 +133,7 @@ struct mmc_omap_host {
int irq;
unsigned char bus_mode;
unsigned char hw_bus_mode;
+ unsigned int
Re: [PATCH 01/13] DSPBRIDGE: Replace mem_calloc() by kzalloc() or __vmalloc()
On Fri, Apr 9, 2010 at 2:43 AM, Gomez Castellanos, Ivan
ivan.go...@ti.com wrote:
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index 75a62b0..6c1b318 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -239,8 +239,8 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32
ulEventMask, u32 dwErrInfo)
printk(KERN_INFO
bridge_deh_notify: DSP_MMUFAULT, fault
address = 0x%x\n, (unsigned int)fault_addr);
- dummy_va_addr =
- (u32) mem_calloc(sizeof(char) * 0x1000,
MEM_PAGED);
+ dummy_va_addr = (u32) kzalloc(sizeof(char) * 0x1000,
+ GFP_ATOMIC);
sizeof(foo) returns the size of foo in chars, so obviously sizeof(char) is 1.
--
Felipe Contreras
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. Daniel -- To unsubscribe from this list: send the line unsubscribe 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] mmc-omap: Add support for 16-bit and 32-bit registers
On Thu, 13 May 2010 12:29:35 -0700 Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100307 09:44]: From: Marek Belisko marek.beli...@open-nandra.com The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring a modification of the register addresses in the mmc-omap driver. To resolve this, a bit shift is performed on base register addresses, either by 1 or 2 bits depending on the CPU in use. This yields the correct registers for each CPU. Signed-off-by: Marek Belisko marek.beli...@open-nandra.com Signed-off-by: Cory Maccarrone darkstar6...@gmail.com Signed-off-by: Tony Lindgren t...@atomide.com Can you please queue this patch too? Ben's comments in this thread were for the i2c-omap, not for this MMC patch. We've had this patch in the omap tree for testing for quite a while now. The patch is also available in at: https://patchwork.kernel.org/patch/83971/ with the direct link to the mbox being: https://patchwork.kernel.org/patch/83971/mbox/ I already have that, as mmc-omap-add-support-for-16-bit-and-32-bit-registers.patch -- To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
* Matthew Garrett m...@redhat.com [100513 12:20]: On Thu, May 13, 2010 at 12:17:17PM -0700, Tony Lindgren wrote: The suspend blocks seems like a hack to spam filter good and bad apps from timer usage point of view. Applications are categorized as good or bad depending if they grab a susped blocker or not. I believe categorizing the apps should be instead done with some timer flags or cgroups instead. I agree, but we have no mechanism for implementing that in a race-free way. We don't even have a realistical proposal for what that mechanism would look like. Should we refuse bread today for the promise of cake tomorrow? Well this is an interesting problem, and once solved will be handy for all kind of things. My worry is that if it's integrated in it's current form it will be totally out of control all over the place :( Still hoping we can come up with some clean way that avoid the patching all over the place part.. How about the following, can you please check if it would help with your example of guaranteed handling of event: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Now to me it sounds if your the input layer and userspace handle both grab the timers with the critical flags, it should be guaranteed that the events get handled before the system is suspended. 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 4/5] musb: use system DMA for unaligned buffers on RTL = 1.8
On Thu, May 13, 2010 at 09:44:11AM +0530, Gupta, Ajay Kumar wrote: Hi, -Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Wednesday, May 12, 2010 11:26 PM To: Sergei Shtylyov Cc: Gupta, Ajay Kumar; linux-...@vger.kernel.org; linux- o...@vger.kernel.org Subject: Re: [PATCH 4/5] musb: use system DMA for unaligned buffers on RTL = 1.8 On Wed, May 12, 2010 at 06:59:52PM +0400, Sergei Shtylyov wrote: Better wrap your stuff into #ifdef OMAP, I think... please don't, better to use the bounce buffer... It would work on blackfin, davinci and omap... Just working is not enough. We need to think of performance and cpu loading as well. allocating a bounce buffer doesn't take long and you can still use mentor DMA to transfer the data. -- balbi -- To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. If the interface is there for a long time, it's because we haven't come up with anything better. And if we haven't come up with anything better, the interface deserves to be there. -- Matthew Garrett | mj...@srcf.ucam.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] mmc-omap: Add support for 16-bit and 32-bit registers
* Andrew Morton a...@linux-foundation.org [100513 12:36]: On Thu, 13 May 2010 12:29:35 -0700 Tony Lindgren t...@atomide.com wrote: * Cory Maccarrone darkstar6...@gmail.com [100307 09:44]: From: Marek Belisko marek.beli...@open-nandra.com The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring a modification of the register addresses in the mmc-omap driver. To resolve this, a bit shift is performed on base register addresses, either by 1 or 2 bits depending on the CPU in use. This yields the correct registers for each CPU. Signed-off-by: Marek Belisko marek.beli...@open-nandra.com Signed-off-by: Cory Maccarrone darkstar6...@gmail.com Signed-off-by: Tony Lindgren t...@atomide.com Can you please queue this patch too? Ben's comments in this thread were for the i2c-omap, not for this MMC patch. We've had this patch in the omap tree for testing for quite a while now. The patch is also available in at: https://patchwork.kernel.org/patch/83971/ with the direct link to the mbox being: https://patchwork.kernel.org/patch/83971/mbox/ I already have that, as mmc-omap-add-support-for-16-bit-and-32-bit-registers.patch OK, thanks. I should have checked your queue first. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Ok. So we stick the untrusted bits of userspace on the critical timer list. Now we get a network packet that generates a wakeup event and gets read by an application. What happens if that application can't fully process the packet in a single timeslice? -- Matthew Garrett | mj...@srcf.ucam.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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
* Matthew Garrett m...@redhat.com [100513 12:49]: On Thu, May 13, 2010 at 12:42:05PM -0700, Tony Lindgren wrote: 1. In the kernel, we add one more timer queue for critical timers. The current timer queue(s) stay as it is. 2. We allow selecting the timer based on some flag, the default behaviour being the current default timer queue. 3. Then we add next_timer_interupt_critical() to only query the critical timers along the lines of the current next_timer_interrupt(). 4. We implement a custom pm_idle that suspends the system based on some logic and checking if next_timer_interrupt_critical() is empty. If the next_timer_interrupt_critical() does not return anything, we assume it's OK to suspend the system. Ok. So we stick the untrusted bits of userspace on the critical timer list. I guess you mean the trusted instead of untrusted apps in the userspace above, the ones that are critical to keep running. Now we get a network packet that generates a wakeup event and gets read by an application. What happens if that application can't fully process the packet in a single timeslice? The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. 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 RFC 1/2] usb: ehci-omap: factor out clock handling
On Thu, May 13, 2010 at 08:30:21PM +0530, Anand Gadiyar wrote:
@@ -190,6 +190,23 @@ struct ehci_hcd_omap {
/*-*/
+static void ehci_omap_clock_power(struct ehci_hcd_omap *omap, int on)
+{
+ if (on) {
+ clk_enable(omap-usbtll_ick);
+ clk_enable(omap-usbtll_fck);
+ clk_enable(omap-usbhost_ick);
+ clk_enable(omap-usbhost1_48m_fck);
+ clk_enable(omap-usbhost2_120m_fck);
+ } else {
+ clk_disable(omap-usbhost2_120m_fck);
+ clk_disable(omap-usbhost1_48m_fck);
+ clk_disable(omap-usbhost_ick);
+ clk_disable(omap-usbtll_fck);
+ clk_disable(omap-usbtll_ick);
+ }
+}
this is sure useful, but it prevents from turning off interface clocks
while we don't need them. AFAICT, we only need interface clocks when we
need to read/write registers. And having a this functions makes things
more difficult to implement that sort of PM optmizations.
Functional clocks should be kept alive for as long as the driver is
probed and not suspended, true. But for the interface clocks we could
enable them dynamicaly when talking to specific register bases. I think
runtime pm can help with that, no ???
Ideally, when you reach suspend, all the activity on the device should
have already stopped, so you'd only need to disable the functional
clocks because interface clocks would have already been disabled due to
not needing them basically. Just needs some investigation on how long
does it take for the clock to actually stabilize and if enabling for
each register read/write is good or bad. IOW, you just need to check
which granularity we need for controlling interface clocks.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. -- Matthew Garrett | mj...@srcf.ucam.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
[PATCH v3 0/5] Adding MMC Support on OMAP4430 SDP
Adding MMC1 and MMC2 controllers support for OMAP4 V3: - Rebased to Mainline version 2.6.34-rc7 - The Patch series has dependencies on I2c, regultor patches. Listing the patches below: [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26256.html [2] http://www.mail-archive.com/linux-...@vger.kernel.org/msg02755.html [3] https://patchwork.kernel.org/patch/94054/ [4] https://patchwork.kernel.org/patch/93918/ [5] https://patchwork.kernel.org/patch/96821/ - Tested on both OMAP4430 SDP and OMAP3430 SDP [Also with omap_hsmmc.c as Kernel Module]. - Compile tested for rest of omap3 boards using omap3_defconfig. Could any one test on other boards V2: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27612.html V1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26858.html Kishore Kadiyala (5): OMAP HSMMC: Adding a flag to determine the card detect type OMAP4 HSMMC: Adding hsmmc support to board file OMAP4 HSMMC: Adding card detect support for MMC1 Controller OMAP4 HSMMC: Adding PBIAS Configuration for MMC1 Controller OMAP4 HSMMC: Enable HSMMC support arch/arm/configs/omap_4430sdp_defconfig | 19 +- arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/board-2430sdp.c |2 + arch/arm/mach-omap2/board-3430sdp.c |3 + arch/arm/mach-omap2/board-4430sdp.c | 64 +++-- arch/arm/mach-omap2/board-cm-t35.c |3 + arch/arm/mach-omap2/board-devkit8000.c |2 + arch/arm/mach-omap2/board-igep0020.c |3 + arch/arm/mach-omap2/board-ldp.c |2 + arch/arm/mach-omap2/board-omap3beagle.c |2 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |4 + arch/arm/mach-omap2/board-omap3touchbook.c |2 + arch/arm/mach-omap2/board-overo.c|3 + arch/arm/mach-omap2/board-rx51-peripherals.c |3 + arch/arm/mach-omap2/board-zoom-peripherals.c |3 + arch/arm/mach-omap2/hsmmc.c | 101 +++--- arch/arm/mach-omap2/hsmmc.h |1 + arch/arm/plat-omap/include/plat/control.h| 20 + arch/arm/plat-omap/include/plat/mmc.h|5 ++ drivers/mfd/twl6030-irq.c| 23 ++ drivers/mmc/host/omap_hsmmc.c| 31 +++-- include/linux/i2c/twl.h | 47 23 files changed, 323 insertions(+), 25 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] OMAP HSMMC: Adding a flag to determine the card detect type
Adding a flag to determine the card detect type which can be
either GPIO or NON-GPIO.MMC1 Controller of OMAP4 has a NON-GPIO
interrupt line from twl6030 for card detect.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 ++
arch/arm/mach-omap2/board-3430sdp.c |3 +++
arch/arm/mach-omap2/board-cm-t35.c |3 +++
arch/arm/mach-omap2/board-devkit8000.c |2 ++
arch/arm/mach-omap2/board-igep0020.c |3 +++
arch/arm/mach-omap2/board-ldp.c |2 ++
arch/arm/mach-omap2/board-omap3beagle.c |2 ++
arch/arm/mach-omap2/board-omap3evm.c |2 ++
arch/arm/mach-omap2/board-omap3pandora.c |4
arch/arm/mach-omap2/board-omap3touchbook.c |2 ++
arch/arm/mach-omap2/board-overo.c|3 +++
arch/arm/mach-omap2/board-rx51-peripherals.c |3 +++
arch/arm/mach-omap2/board-zoom-peripherals.c |3 +++
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h|4
15 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 01d113f..466c4a8 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -37,6 +37,7 @@
#include plat/gpmc.h
#include plat/usb.h
#include plat/gpmc-smc91x.h
+#include plat/mmc.h
#include hsmmc.h
@@ -187,6 +188,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.mmc= 1,
.wires = 4,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp= -EINVAL,
.ext_clock = 1,
},
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 5822bcf..85d0e09 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -40,6 +40,7 @@
#include plat/control.h
#include plat/gpmc-smc91x.h
+#include plat/mmc.h
#include mach/board-sdp.h
@@ -355,11 +356,13 @@ static struct omap2_hsmmc_info mmc[] = {
* so the SIM card isn't used; else 4 bits.
*/
.wires = 8,
+ .cd_type= GPIO,
.gpio_wp= 4,
},
{
.mmc= 2,
.wires = 8,
+ .cd_type= GPIO,
.gpio_wp= 7,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 2de4f79..a6ce29e 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -45,6 +45,7 @@
#include plat/gpmc.h
#include plat/usb.h
#include plat/display.h
+#include plat/mmc.h
#include mach/hardware.h
@@ -598,6 +599,7 @@ static struct omap2_hsmmc_info mmc[] = {
.mmc= 1,
.wires = 4,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp= -EINVAL,
},
@@ -606,6 +608,7 @@ static struct omap2_hsmmc_info mmc[] = {
.wires = 4,
.transceiver= 1,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp= -EINVAL,
.ocr_mask = 0x0010, /* 3.3V */
},
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 47e3af2..c880546 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -45,6 +45,7 @@
#include plat/usb.h
#include plat/timer-gp.h
#include plat/display.h
+#include plat/mmc.h
#include plat/mcspi.h
#include linux/input/matrix_keypad.h
@@ -122,6 +123,7 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.wires = 8,
+ .cd_type= GPIO,
.gpio_wp= 29,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index d55c57b..3d5d506 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -30,6 +30,7 @@
#include plat/usb.h
#include plat/display.h
#include plat/onenand.h
+#include plat/mmc.h
#include mux.h
#include hsmmc.h
@@ -250,12 +251,14 @@ static struct omap2_hsmmc_info mmc[] = {
.mmc= 1,
.wires = 4,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp= -EINVAL,
},
{
.mmc= 2,
.wires = 4,
.gpio_cd= -EINVAL,
+ .cd_type= GPIO,
.gpio_wp
[PATCH v3 2/5] OMAP4 HSMMC: Adding hsmmc support to board file
Support for MMC1 MMC2 controllers is added to the board file.
Also includes configuration of MMC1 Card detect initially.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-4430sdp.c | 64 +++
include/linux/i2c/twl.h | 44
3 files changed, 103 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ffe600a..65d8d11 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -140,7 +140,8 @@ obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
hsmmc.o
-obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o
+obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o \
+ hsmmc.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index d86e22d..70c8ab7 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -32,6 +32,8 @@
#include plat/control.h
#include plat/timer-gp.h
#include plat/usb.h
+#include plat/mmc.h
+#include hsmmc.h
static struct platform_device sdp4430_lcd_device = {
.name = sdp4430_lcd,
@@ -68,24 +70,71 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
-static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
- {
- .supply = vmmc,
- },
+static struct omap2_hsmmc_info mmc[] = {
{
- .supply = vmmc,
+ .mmc= 1,
+ .wires = 8,
+ .gpio_cd= TWL6030_IRQ_BASE + MMCDETECT_INTR_OFFSET,
+ .cd_type= NON_GPIO,
+ .gpio_wp= -EINVAL,
},
{
- .supply = vmmc,
+ .mmc= 2,
+ .wires = 8,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .nonremovable = true,
},
+ {} /* Terminator */
+};
+
+static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
{
.supply = vmmc,
+ .dev_name = mmci-omap-hs.0,
},
{
.supply = vmmc,
+ .dev_name = mmci-omap-hs.1,
},
};
+static int omap4_twl6030_hsmmc_late_init(struct device *dev)
+{
+ int ret = 0;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ struct omap_mmc_platform_data *pdata = dev-platform_data;
+
+ /* MMC1 Card detect Configuration */
+ if (pdev-id == 0) {
+ ret = omap4_hsmmc1_card_detect_config();
+ if (ret 0)
+ pr_err(Unable to configure Card detect for MMC1\n);
+ pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
+ MMCDETECT_INTR_OFFSET;
+ }
+ return ret;
+}
+
+static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
+{
+ struct omap_mmc_platform_data *pdata = dev-platform_data;
+
+ pdata-init = omap4_twl6030_hsmmc_late_init;
+}
+
+static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
*controllers)
+{
+ struct omap2_hsmmc_info *c;
+
+ omap2_hsmmc_init(controllers);
+ for (c = controllers; c-mmc; c++)
+ omap4_twl6030_hsmmc_set_late_init(c-dev);
+
+ return 0;
+}
+
static struct regulator_init_data sdp4430_vaux1 = {
.constraints = {
.min_uV = 100,
@@ -137,7 +186,7 @@ static struct regulator_init_data sdp4430_vmmc = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 5,
+ .num_consumer_supplies = 2,
.consumer_supplies = sdp4430_vmmc_supply,
};
@@ -256,6 +305,7 @@ static void __init omap_4430sdp_init(void)
omap4_i2c_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
+ omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 SDP uses internal transceiver so register nop transceiver */
usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index fb6784e..f382d59 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -141,6 +141,15 @@
#define TWL6030_CHARGER_CTRL_INT_MASK 0x10
#define TWL6030_CHARGER_FAULT_INT_MASK
[PATCH v3 3/5] OMAP4 HSMMC: Adding card detect support for MMC1 Controller
Adds card detect callback function which gives the status of
the card.For MMC1 Controller, Card detect interrupt is provided by
twl6030 and card status is provided by MMCCTRL reg of twl6030.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/hsmmc.c |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mfd/twl6030-irq.c | 23 +++
drivers/mmc/host/omap_hsmmc.c | 31 ++-
include/linux/i2c/twl.h |3 +++
5 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 9ad2295..679188c 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -189,6 +189,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc-get_context_loss_count = hsmmc_get_context_loss;
mmc-slots[0].switch_pin = c-gpio_cd;
+ mmc-slots[0].cd_type = c-cd_type;
mmc-slots[0].gpio_wp = c-gpio_wp;
mmc-slots[0].remux = c-remux;
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index e4e595b..38fa033 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -14,6 +14,7 @@
#include linux/types.h
#include linux/device.h
#include linux/mmc/host.h
+#include linux/i2c/twl.h
#include plat/board.h
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..ca8b30b 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -223,6 +223,29 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect(int host_id, int slot)
+{
+ int ret = -ENOSYS;
+ u8 read_reg;
+
+ switch (host_id) {
+ case 0:
+ /*
+* BIT0 of REG_MMC_CTRL
+* 0 - Card not present ,1 - Card present
+*/
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0,
+ read_reg, TWL6030_MMCCTRL);
+ if (ret = 0)
+ ret = read_reg STS_MMC;
+ break;
+ default:
+ pr_err(Unkown MMC controller %d in %s\n, host_id, __func__);
+ }
+ return ret;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect);
+
int twl6030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end)
{
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e9caf69..e25db63 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -190,9 +190,16 @@ struct omap_hsmmc_host {
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ int ret = -ENOSYS;
- /* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc-slots[0].switch_pin);
+ if (mmc-slots[0].cd_type == GPIO)
+ /* NOTE: assumes card detect signal is active-low */
+ ret = !gpio_get_value_cansleep(mmc-slots[0].switch_pin);
+ else
+ ret = twl6030_mmc_card_detect(pdev-id, slot);
+ return ret;
}
static int omap_hsmmc_get_wp(struct device *dev, int slot)
@@ -465,8 +472,6 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
int ret;
if (gpio_is_valid(pdata-slots[0].switch_pin)) {
- pdata-suspend = omap_hsmmc_suspend_cdirq;
- pdata-resume = omap_hsmmc_resume_cdirq;
if (pdata-slots[0].cover)
pdata-slots[0].get_cover_state =
omap_hsmmc_get_cover_state;
@@ -505,6 +510,16 @@ err_free_sp:
return ret;
}
+static int omap_hsmmc_non_gpio_init(struct omap_mmc_platform_data *pdata)
+{
+
+ if (pdata-slots[0].switch_pin 0) {
+ pdata-slots[0].card_detect = omap_hsmmc_card_detect;
+ pdata-slots[0].card_detect_irq = pdata-slots[0].switch_pin;
+ }
+ return 0;
+}
+
static void omap_hsmmc_gpio_free(struct omap_mmc_platform_data *pdata)
{
if (gpio_is_valid(pdata-slots[0].gpio_wp))
@@ -1977,7 +1992,11 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
if (res == NULL)
return -EBUSY;
- ret = omap_hsmmc_gpio_init(pdata);
+ if (pdata-slots[0].cd_type == GPIO)
+ ret = omap_hsmmc_gpio_init(pdata);
+ else
+ ret = omap_hsmmc_non_gpio_init(pdata);
+
if (ret)
goto err;
@@ -2160,6 +2179,8 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
Unable to grab MMC CD IRQ\n);
goto
[PATCH v3 4/5] OMAP4 HSMMC: Adding PBIAS Configuration for MMC1 Controller
In OMAP4 , MMC1 PBIAS and its associated IO is software-controlled
by CONTROL_PBIAS and CONTROL_MMC1 registers. This patch adds PBIAS
configuration for MMC1 Controller during power-ON and power-OFF
of regulator.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/hsmmc.c | 100 +---
arch/arm/plat-omap/include/plat/control.h | 20 ++
2 files changed, 109 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 679188c..0d7fffb 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -24,6 +24,7 @@
static u16 control_pbias_offset;
static u16 control_devconf1_offset;
+static u16 control_mmc1;
#define HSMMC_NAME_LEN 9
@@ -42,7 +43,7 @@ static int hsmmc_get_context_loss(struct device *dev)
#define hsmmc_get_context_loss NULL
#endif
-static void hsmmc1_before_set_reg(struct device *dev, int slot,
+static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
u32 reg, prog_io;
@@ -95,7 +96,7 @@ static void hsmmc1_before_set_reg(struct device *dev, int
slot,
}
}
-static void hsmmc1_after_set_reg(struct device *dev, int slot,
+static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
u32 reg;
@@ -119,6 +120,60 @@ static void hsmmc1_after_set_reg(struct device *dev, int
slot,
}
}
+static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
+ int power_on, int vdd)
+{
+ u32 reg;
+
+ /*
+* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
+* card with Vcc regulator (from twl4030 or whatever). OMAP has both
+* 1.8V and 3.0V modes, controlled by the PBIAS register.
+*
+* In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a supply, which
+* is most naturally TWL VSIM; those pins also use PBIAS.
+*
+* FIXME handle VMMC1A as needed ...
+*/
+ reg = omap_ctrl_readl(control_pbias_offset);
+ reg = ~(OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ |
+ OMAP4_USBC1_ICUSB_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+}
+
+static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
+int power_on, int vdd)
+{
+ u32 reg;
+
+ if (power_on) {
+ reg = omap_ctrl_readl(control_pbias_offset);
+ reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ;
+ if ((1 vdd) = MMC_VDD_165_195)
+ reg = ~OMAP4_MMC1_PBIASLITE_VMODE;
+ else
+ reg |= OMAP4_MMC1_PBIASLITE_VMODE;
+ reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ |
+ OMAP4_USBC1_ICUSB_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+ /* 4 microsec delay for comparator to generate an error*/
+ udelay(4);
+ reg = omap_ctrl_readl(control_pbias_offset);
+ if (reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR) {
+ pr_err(Pbias Voltage is not same as LDO\n);
+ /* Caution : On VMODE_ERROR Power Down MMC IO */
+ reg = ~(OMAP4_MMC1_PWRDNZ | OMAP4_USBC1_ICUSB_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+ }
+ } else {
+ reg = omap_ctrl_readl(control_pbias_offset);
+reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
+ OMAP4_MMC1_PBIASLITE_VMODE | OMAP4_MMC1_PWRDNZ |
+ OMAP4_USBC1_ICUSB_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+ }
+}
+
static void hsmmc23_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
@@ -146,13 +201,28 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
struct omap2_hsmmc_info *c;
int nr_hsmmc = ARRAY_SIZE(hsmmc_data);
int i;
+ u32 reg;
- if (cpu_is_omap2430()) {
- control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
- control_devconf1_offset = OMAP243X_CONTROL_DEVCONF1;
+ if (!cpu_is_omap44xx()) {
+ if (cpu_is_omap2430()) {
+ control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
+ control_devconf1_offset = OMAP243X_CONTROL_DEVCONF1;
+ } else {
+ control_pbias_offset = OMAP343X_CONTROL_PBIAS_LITE;
+ control_devconf1_offset = OMAP343X_CONTROL_DEVCONF1;
+ }
} else {
- control_pbias_offset = OMAP343X_CONTROL_PBIAS_LITE;
- control_devconf1_offset = OMAP343X_CONTROL_DEVCONF1;
+
[PATCH v3 5/5] OMAP4 HSMMC: Enable HSMMC support
Enables HSMMC support for OMAP4430 defconfig Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index b7ddc7a..d6b9c5d 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -552,7 +552,24 @@ CONFIG_DUMMY_CONSOLE=y # CONFIG_SOUND is not set # CONFIG_HID_SUPPORT is not set # CONFIG_USB_SUPPORT is not set -# CONFIG_MMC is not set +CONFIG_MMC=y +# CONFIG_MMC_DEBUG is not set +# CONFIG_MMC_UNSAFE_RESUME is not set + +# +# MMC/SD/SDIO Card Drivers +# +CONFIG_MMC_BLOCK=y +CONFIG_MMC_BLOCK_BOUNCE=y +# CONFIG_SDIO_UART is not set +# CONFIG_MMC_TEST is not set + +# +# MMC/SD/SDIO Host Controller Drivers +# +# CONFIG_MMC_SDHCI is not set +# CONFIG_MMC_OMAP is not set +CONFIG_MMC_OMAP_HS=y # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
* Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. Hmm, if you use timer slack then you still need to search through the whole timer list instead of a smaller critical timer list. Both ways sound doable though. 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. And if that's the application that's listening to the network socket that you want to get a wakeup event from? This problem is hard. I'd love there to be an elegant solution based on using the scheduler, but I really don't know what it is. -- Matthew Garrett | mj...@srcf.ucam.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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 13:23 -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. Couldn't you just use priorities (nice), or cgroups to deal with that? I'm sure there is a way to limit an apps runtime, so the system does go idle sometimes. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. Hmm, if you use timer slack then you still need to search through the whole timer list instead of a smaller critical timer list. Both ways sound doable though. There are deferrable timers already in Linux.. It seems like it would just be an extension of that. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] dspbridge: deh: fix memory corruption on faults
Hi, Long story short: we shouldn't send buffers that are not page-aligned for MMU fault recovery. In fact, there's no need to send anything at all. For more information, see: http://thread.gmane.org/gmane.linux.ports.arm.omap/33926/focus=34207 Felipe Contreras (2): dspbridge: deh: fix corruption on MMU fault dspbridge: deh: remove unused code arch/arm/plat-omap/include/dspbridge/wmddeh.h |1 - drivers/dsp/bridge/rmgr/proc.c|7 +--- drivers/dsp/bridge/wmd/_tiomap.h |4 -- drivers/dsp/bridge/wmd/tiomap3430.c |2 - drivers/dsp/bridge/wmd/ue_deh.c | 48 + 5 files changed, 2 insertions(+), 60 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] dspbridge: deh: fix corruption on MMU fault
... by removing unnecessary fault handling.
From the looks of it, when an MMU fault happens, the DSP wants us to
come up with the data that is supposed to be on the faulty address.
Clearly, there's no way to provide that information, and such errors are
fatal, so there's no point in allocating a buffer and mapping it.
Moreover, kmalloc() doesn't return paged memory, so if the DSP tries to
write to an unaligned buffer, memory corruption ensures.
Based on the analysis of Fernando Guzman Lugo and Deepak Chitriki:
http://article.gmane.org/gmane.linux.ports.arm.omap/34207
I tested a similar patch on Nokia custom hardware and memory corruption
was gone. I tested this particular patch on a beagleboard, and although
I was never able to reproduce the corruption, it didn't cause any
further problems.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/wmd/ue_deh.c | 28
1 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index 03b29b6..233ad17 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -62,13 +62,6 @@
/* Max time to check for GP Timer IRQ */
#define GPTIMER_IRQ_WAIT_MAX_CNT 1000
-static struct hw_mmu_map_attrs_t map_attrs = { HW_LITTLE_ENDIAN,
- HW_ELEM_SIZE16BIT,
- HW_MMU_CPUES
-};
-
-static void *dummy_va_addr;
-
static struct omap_dm_timer *timer;
dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
@@ -84,7 +77,6 @@ dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
/* Get WMD context info. */
dev_get_wmd_context(hdev_obj, hwmd_context);
DBC_ASSERT(hwmd_context);
- dummy_va_addr = NULL;
/* Allocate IO manager object: */
deh_mgr = kzalloc(sizeof(struct deh_mgr), GFP_KERNEL);
if (!deh_mgr) {
@@ -190,12 +182,8 @@ dsp_status bridge_deh_register_notify(struct deh_mgr
*deh_mgr, u32 event_mask,
void bridge_deh_notify(struct deh_mgr *deh_mgr, u32 ulEventMask, u32 dwErrInfo)
{
struct wmd_dev_context *dev_context;
- dsp_status status = DSP_SOK;
- u32 mem_physical = 0;
u32 hw_mmu_max_tlb_count = 31;
extern u32 fault_addr;
- struct cfg_hostres *resources;
- hw_status hw_status_obj;
u32 cnt = 0;
if (!deh_mgr)
@@ -203,7 +191,6 @@ void bridge_deh_notify(struct deh_mgr *deh_mgr, u32
ulEventMask, u32 dwErrInfo)
dev_info(bridge, %s: device exception\n, __func__);
dev_context = (struct wmd_dev_context *)deh_mgr-hwmd_context;
- resources = dev_context-resources;
switch (ulEventMask) {
case DSP_SYSERROR:
@@ -228,9 +215,6 @@ void bridge_deh_notify(struct deh_mgr *deh_mgr, u32
ulEventMask, u32 dwErrInfo)
(unsigned int) deh_mgr-err_info.dw_val1,
(unsigned int) deh_mgr-err_info.dw_val2,
(unsigned int) fault_addr);
- dummy_va_addr = kzalloc(sizeof(char) * 0x1000, GFP_ATOMIC);
- mem_physical =
- ALIGN_DOWN(virt_to_phys(dummy_va_addr), PAGE_SIZE);
dev_context = (struct wmd_dev_context *)
deh_mgr-hwmd_context;
@@ -247,13 +231,6 @@ void bridge_deh_notify(struct deh_mgr *deh_mgr, u32
ulEventMask, u32 dwErrInfo)
dev_context-num_tlb_entries =
dev_context-fixed_tlb_entries;
}
- if (DSP_SUCCEEDED(status)) {
- hw_status_obj =
- hw_mmu_tlb_add(resources-dw_dmmu_base,
- mem_physical, fault_addr,
- HW_PAGE_SIZE4KB, 1,
- map_attrs, HW_SET, HW_SET);
- }
/*
* Send a GP Timer interrupt to DSP.
@@ -286,9 +263,6 @@ void bridge_deh_notify(struct deh_mgr *deh_mgr, u32
ulEventMask, u32 dwErrInfo)
}
}
- /* Clear MMU interrupt */
- hw_mmu_event_ack(resources-dw_dmmu_base,
- HW_MMU_TRANSLATION_FAULT);
dump_dsp_stack(deh_mgr-hwmd_context);
omap_dm_timer_disable(timer);
break;
@@ -356,6 +330,4 @@ dsp_status bridge_deh_get_info(struct deh_mgr *deh_mgr,
void bridge_deh_release_dummy_mem(void)
{
- kfree(dummy_va_addr);
- dummy_va_addr = NULL;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] dspbridge: deh: remove unused code
And a few cleanups.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/wmddeh.h |1 -
drivers/dsp/bridge/rmgr/proc.c|7 +--
drivers/dsp/bridge/wmd/_tiomap.h |4
drivers/dsp/bridge/wmd/tiomap3430.c |2 --
drivers/dsp/bridge/wmd/ue_deh.c | 20 +---
5 files changed, 2 insertions(+), 32 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wmddeh.h
b/arch/arm/plat-omap/include/dspbridge/wmddeh.h
index 6f9a788..afe19c7 100644
--- a/arch/arm/plat-omap/include/dspbridge/wmddeh.h
+++ b/arch/arm/plat-omap/include/dspbridge/wmddeh.h
@@ -43,5 +43,4 @@ extern dsp_status bridge_deh_register_notify(struct deh_mgr
*deh_mgr,
extern void bridge_deh_notify(struct deh_mgr *deh_mgr,
u32 ulEventMask, u32 dwErrInfo);
-extern void bridge_deh_release_dummy_mem(void);
#endif /* WMDDEH_ */
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index c163829..794ff63 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -1357,18 +1357,12 @@ dsp_status proc_stop(void *hprocessor)
u32 node_tab_size = 1;
u32 num_nodes = 0;
u32 nodes_allocated = 0;
- int brd_state;
DBC_REQUIRE(refs 0);
if (!p_proc_object) {
status = -EFAULT;
goto func_end;
}
- if (DSP_SUCCEEDED((*p_proc_object-intf_fxns-pfn_brd_status)
- (p_proc_object-hwmd_context, brd_state))) {
- if (brd_state == BRD_ERROR)
- bridge_deh_release_dummy_mem();
- }
/* check if there are any running nodes */
status = dev_get_node_manager(p_proc_object-hdev_obj, hnode_mgr);
if (DSP_SUCCEEDED(status) hnode_mgr) {
@@ -1390,6 +1384,7 @@ dsp_status proc_stop(void *hprocessor)
p_proc_object-proc_state = PROC_STOPPED;
/* Destory the Node Manager, msg_ctrl Manager */
if (DSP_SUCCEEDED(dev_destroy2(p_proc_object-hdev_obj))) {
+ int brd_state;
/* Destroy the msg_ctrl by calling msg_delete */
dev_get_msg_mgr(p_proc_object-hdev_obj, hmsg_mgr);
if (hmsg_mgr) {
diff --git a/drivers/dsp/bridge/wmd/_tiomap.h b/drivers/dsp/bridge/wmd/_tiomap.h
index bf3b849..d73b130 100644
--- a/drivers/dsp/bridge/wmd/_tiomap.h
+++ b/drivers/dsp/bridge/wmd/_tiomap.h
@@ -341,10 +341,6 @@ struct wmd_dev_context {
/* DMMU TLB entries */
struct wmdioctl_extproc atlb_entry[WMDIOCTL_NUMOFMMUTLB];
u32 dw_brd_state; /* Last known board state. */
- u32 ul_int_mask;/* int mask */
- u16 io_base;/* Board I/O base */
- u32 num_tlb_entries;/* DSP MMU TLB entry counter */
- u32 fixed_tlb_entries; /* Fixed DSPMMU TLB entry count */
/* TC Settings */
bool tc_word_swap_on; /* Traffic Controller Word Swap */
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index a69f663..cf4b28a 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -900,7 +900,6 @@ static dsp_status bridge_dev_create(OUT struct
wmd_dev_context **ppDevContext,
dev_context-atlb_entry[entry_ndx].ul_gpp_pa =
dev_context-atlb_entry[entry_ndx].ul_dsp_va = 0;
}
- dev_context-num_tlb_entries = 0;
dev_context-dw_dsp_base_addr = (u32) MEM_LINEAR_ADDRESS((void *)
(pConfig-
dw_mem_base
@@ -1003,7 +1002,6 @@ static dsp_status bridge_dev_create(OUT struct
wmd_dev_context **ppDevContext,
}
if (DSP_SUCCEEDED(status)) {
dev_context-hdev_obj = hdev_obj;
- dev_context-ul_int_mask = 0;
/* Store current board state. */
dev_context-dw_brd_state = BRD_STOPPED;
dev_context-resources = resources;
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index 233ad17..c39f56f 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -138,8 +138,6 @@ dsp_status bridge_deh_destroy(struct deh_mgr *deh_mgr)
if (!deh_mgr)
return -EFAULT;
- /* Release dummy VA buffer */
- bridge_deh_release_dummy_mem();
/* If notification object exists, delete it */
if (deh_mgr-ntfy_obj) {
ntfy_delete(deh_mgr-ntfy_obj);
@@ -182,9 +180,7 @@ dsp_status bridge_deh_register_notify(struct deh_mgr
*deh_mgr, u32 event_mask,
void bridge_deh_notify(struct deh_mgr *deh_mgr, u32 ulEventMask, u32 dwErrInfo)
{
struct wmd_dev_context *dev_context;
- u32 hw_mmu_max_tlb_count = 31;
extern u32
[RFC] [PATCH 0/4] OMAP4 Keyboard Controller Support
Keyboard controller for OMAP4 includes - built-in scanning algorithm - debouncing feature - handling mechanism up to 9 x 9 keys - wake-up event generation Dependency on hwmod changes for OMAP4 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28188.html -- v1 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26502.html v2 Vimal.Singh.01 | Signed-off-by missing in patch Vimal.Singh.02 | row/column interpretation in board file Vimal.Singh.03 | 0 element removal in board file Trilok.Soni.01 | hwmod framework in mainline Trilok.Soni.02 | extra brackets in Kconfig Trilok.Soni.03 | default y/n option in Kconfig Trilok.Soni.04 | path/filename in the header of driver Trilok.Soni.05 | static? omap_device_pm_latency in driver Trilok.Soni.06 | input_sync added in driver Trilok.Soni.07 | check error return in all driver Trilok.Soni.08 | keypad_data-input=NULL Felipe.Balbi.01 | platform_driver to know about hwmod and omap_device? Felipe.Balbi.02 | blank line Felipe.Balbi.03 | saving struct device * Felipe.Balbi.04 | platform_data should not be saved Felipe.Balbi.05 | dev_dbg() usage Felipe.Balbi.06 | missing input_sync() Felipe.Balbi.07 | snprintf() usage Felipe.Balbi.08 | omap_hwmod and omap_device location Felipe.Balbi.09 | matrix_keypad_platform_data allocation from platform code Felipe.Balbi.10 | omap_device_build from platform code Felipe.Balbi.11 | registering/configuring call location Kevin.Hillman.01 | Driver Testing Kevin.Hillman.02 | omap_hwmod and omap_device location Dmitry.Torokhov.01 | reason to make omap_keypad_threaded threaded? Dmitry.Torokhov.02 | MATRIX_SCAN_CODE and incorrect values Dmitry.Torokhov.03 | matrix_keypad_platform_data allocation Dmitry.Torokhov.04 | overriding pdata pointer Dmitry.Torokhov.05 | keypad_codes separate allocation Dmitry.Torokhov.06 | keypad_data-base check location Dmitry.Torokhov.07 | keypad_data-irq check location Dmitry.Torokhov.08 | input_dev-keycodemax needed Dmitry.Torokhov.09 | KEY_OK set bit Dmitry.Torokhov.10 | MSC_SCAN report missing Dmitry.Torokhov.11 | input_dev = NULL; Dmitry.Torokhov.12 | free_irq call location in remove function -- [PATCH v2 1/4] Input: matrix_keypad: Device driver interfaces [PATCH v2 2/4] OMAP4: Keyboard controller support [PATCH v2 3/4] OMAP4: Keyboard board support [PATCH v2 4/4] OMAP4: Keyboard kernel configuration -- arch/arm/configs/omap_4430sdp_defconfig |3 arch/arm/mach-omap2/board-4430sdp.c | 157 drivers/input/keyboard/Kconfig | 10 + drivers/input/keyboard/Makefile |1 drivers/input/keyboard/omap4-keypad.c | 304 include/linux/input/matrix_keypad.h |7 6 files changed, 481 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe 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] [PATCH v2 1/4] Input: matrix_keypad: Device driver interfaces
Add omap device driver interfaces to enable hwmod framework
Signed-off-by: Abraham Arce x0066...@ti.com
---
include/linux/input/matrix_keypad.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/input/matrix_keypad.h
b/include/linux/input/matrix_keypad.h
index c964cd7..552e11d 100644
--- a/include/linux/input/matrix_keypad.h
+++ b/include/linux/input/matrix_keypad.h
@@ -66,6 +66,13 @@ struct matrix_keypad_platform_data {
boolactive_low;
boolwakeup;
boolno_autorepeat;
+
+ void __iomem *base;
+ u16 irq;
+
+ int (*device_enable) (struct platform_device *pdev);
+ int (*device_shutdown) (struct platform_device *pdev);
+ int (*device_idle) (struct platform_device *pdev);
};
/**
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH v2 2/4] OMAP4: Keyboard controller support
OMAP4 keyboard controller includes:
- built-in scanning algorithm
- debouncing feature
Driver implementation is based on matrix_keypac.c
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Abraham Arce x0066...@ti.com
---
drivers/input/keyboard/Kconfig| 10 +
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/omap4-keypad.c | 304 +
3 files changed, 315 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/keyboard/omap4-keypad.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 64c1023..9e1c5d5 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -403,6 +403,16 @@ config KEYBOARD_OMAP
To compile this driver as a module, choose M here: the
module will be called omap-keypad.
+config KEYBOARD_OMAP4
+tristate TI OMAP4 keypad support
+depends on ARCH_OMAP4
+ default n
+help
+ Say Y here if you want to use the OMAP4 keypad.
+
+ To compile this driver as a module, choose M here: the
+ module will be called omap-keypad.
+
config KEYBOARD_TWL4030
tristate TI TWL4030/TWL5030/TPS659x0 keypad support
depends on TWL4030_CORE
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 706c6b5..7e2987e 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_KEYBOARD_MATRIX) += matrix_keypad.o
obj-$(CONFIG_KEYBOARD_MAX7359) += max7359_keypad.o
obj-$(CONFIG_KEYBOARD_NEWTON) += newtonkbd.o
obj-$(CONFIG_KEYBOARD_OMAP)+= omap-keypad.o
+obj-$(CONFIG_KEYBOARD_OMAP4) += omap4-keypad.o
obj-$(CONFIG_KEYBOARD_OPENCORES) += opencores-kbd.o
obj-$(CONFIG_KEYBOARD_PXA27x) += pxa27x_keypad.o
obj-$(CONFIG_KEYBOARD_PXA930_ROTARY) += pxa930_rotary.o
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
new file mode 100644
index 000..e8bac82
--- /dev/null
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -0,0 +1,304 @@
+/*
+ * omap4-keypad.c
+ *
+ * OMAP4 Keypad Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author: Abraham Arce x0066...@ti.com
+ * Initial Code: Syed Rafiuddin rafiuddin.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 as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/errno.h
+#include linux/io.h
+#include linux/input.h
+#include linux/input/matrix_keypad.h
+#include linux/slab.h
+
+/* OMAP4 registers */
+#define OMAP4_KBD_REVISION 0x00
+#define OMAP4_KBD_SYSCONFIG0x10
+#define OMAP4_KBD_SYSSTATUS0x14
+#define OMAP4_KBD_IRQSTATUS0x18
+#define OMAP4_KBD_IRQENABLE0x1C
+#define OMAP4_KBD_WAKEUPENABLE 0x20
+#define OMAP4_KBD_PENDING 0x24
+#define OMAP4_KBD_CTRL 0x28
+#define OMAP4_KBD_DEBOUNCINGTIME 0x2C
+#define OMAP4_KBD_LONGKEYTIME 0x30
+#define OMAP4_KBD_TIMEOUT 0x34
+#define OMAP4_KBD_STATEMACHINE 0x38
+#define OMAP4_KBD_ROWINPUTS0x3C
+#define OMAP4_KBD_COLUMNOUTPUTS0x40
+#define OMAP4_KBD_FULLCODE31_0 0x44
+#define OMAP4_KBD_FULLCODE63_320x48
+
+/* OMAP4 bit definitions */
+#define OMAP4_DEF_SYSCONFIG_SOFTRST(1 1)
+#define OMAP4_DEF_SYSCONFIG_ENAWKUP(1 2)
+#define OMAP4_DEF_IRQENABLE_EVENTEN(1 0)
+#define OMAP4_DEF_IRQENABLE_LONGKEY(1 1)
+#define OMAP4_DEF_IRQENABLE_TIMEOUTEN (1 2)
+#define OMAP4_DEF_CTRL_NOSOFTMODE (1 1)
+#define OMAP4_DEF_CTRLPTVVALUE (1 2)
+#define OMAP4_DEF_CTRLPTV (1 1)
+#define OMAP4_DEF_IRQDISABLE 0x00
+
+/* OMAP4 values */
+#define OMAP4_VAL_DEBOUNCINGTIME 0x07
+#define OMAP4_VAL_FUNCTIONALCFG0x1E
+
+#define OMAP4_MASK_IRQSTATUSDISABLE0x
+
+struct omap_keypad {
+ struct input_dev *input;
+ struct platform_device *pdev;
+
+ void __iomem*base;
+ int irq;
+
+ unsigned short *keycodes;
+ unsigned int rows;
+ unsigned int cols;
+ unsigned int row_shift;
+
[RFC] [PATCH v2 3/4] OMAP4: Keyboard board support
Keyboard support for SDP OMAP4430
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 157 +++
1 files changed, 157 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 6cce6f2..19742c5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -19,6 +19,8 @@
#include linux/gpio.h
#include linux/usb/otg.h
#include linux/spi/spi.h
+#include linux/input.h
+#include linux/input/matrix_keypad.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -31,11 +33,161 @@
#include plat/control.h
#include plat/timer-gp.h
#include plat/usb.h
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+static int sdp4430_keymap[] = {
+ KEY(0, 0, KEY_E),
+ KEY(0, 1, KEY_R),
+ KEY(0, 2, KEY_T),
+ KEY(0, 3, KEY_HOME),
+ KEY(0, 4, KEY_F5),
+ KEY(0, 5, KEY_UNKNOWN),
+ KEY(0, 6, KEY_I),
+ KEY(0, 7, KEY_LEFTSHIFT),
+
+ KEY(1, 0, KEY_D),
+ KEY(1, 1, KEY_F),
+ KEY(1, 2, KEY_G),
+ KEY(1, 3, KEY_SEND),
+ KEY(1, 4, KEY_F6),
+ KEY(1, 5, KEY_UNKNOWN),
+ KEY(1, 6, KEY_K),
+ KEY(1, 7, KEY_ENTER),
+
+ KEY(2, 0, KEY_X),
+ KEY(2, 1, KEY_C),
+ KEY(2, 2, KEY_V),
+ KEY(2, 3, KEY_END),
+ KEY(2, 4, KEY_F7),
+ KEY(2, 5, KEY_UNKNOWN),
+ KEY(2, 6, KEY_DOT),
+ KEY(2, 7, KEY_CAPSLOCK),
+
+ KEY(3, 0, KEY_Z),
+ KEY(3, 1, KEY_KPPLUS),
+ KEY(3, 2, KEY_B),
+ KEY(3, 3, KEY_F1),
+ KEY(3, 4, KEY_F8),
+ KEY(3, 5, KEY_UNKNOWN),
+ KEY(3, 6, KEY_O),
+ KEY(3, 7, KEY_SPACE),
+
+ KEY(4, 0, KEY_W),
+ KEY(4, 1, KEY_Y),
+ KEY(4, 2, KEY_U),
+ KEY(4, 3, KEY_F2),
+ KEY(4, 4, KEY_VOLUMEUP),
+ KEY(4, 5, KEY_UNKNOWN),
+ KEY(4, 6, KEY_L),
+ KEY(4, 7, KEY_LEFT),
+
+ KEY(5, 0, KEY_S),
+ KEY(5, 1, KEY_H),
+ KEY(5, 2, KEY_J),
+ KEY(5, 3, KEY_F3),
+ KEY(5, 4, KEY_F9),
+ KEY(5, 5, KEY_VOLUMEDOWN),
+ KEY(5, 6, KEY_M),
+ KEY(5, 7, KEY_RIGHT),
+
+ KEY(6, 0, KEY_Q),
+ KEY(6, 1, KEY_A),
+ KEY(6, 2, KEY_N),
+ KEY(6, 3, KEY_BACK),
+ KEY(6, 4, KEY_BACKSPACE),
+ KEY(6, 5, KEY_UNKNOWN),
+ KEY(6, 6, KEY_P),
+ KEY(6, 7, KEY_UP),
+
+ KEY(7, 0, KEY_PROG1),
+ KEY(7, 1, KEY_PROG2),
+ KEY(7, 2, KEY_PROG3),
+ KEY(7, 3, KEY_PROG4),
+ KEY(7, 4, KEY_F4),
+ KEY(7, 5, KEY_UNKNOWN),
+ KEY(7, 6, KEY_OK),
+ KEY(7, 7, KEY_DOWN),
+};
+
+static struct matrix_keymap_data sdp4430_keymap_data = {
+ .keymap = sdp4430_keymap,
+ .keymap_size= ARRAY_SIZE(sdp4430_keymap),
+};
+
+static struct matrix_keypad_platform_data sdp4430_keypad_data = {
+ .keymap_data= sdp4430_keymap_data,
+ .num_row_gpios = 8,
+ .num_col_gpios = 8,
+ .device_enable = omap_device_enable,
+ .device_shutdown= omap_device_shutdown,
+ .device_idle= omap_device_idle,
+};
+
+static struct platform_device sdp4430_keypad_device = {
+ .name = omap4-keypad,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_keypad_data,
+ },
+};
+
+struct omap_device_pm_latency omap_keyboard_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+struct omap_device *od;
+
+static int __init sdp4430_keypad_init(void)
+{
+ struct omap_hwmod *oh;
+ struct matrix_keypad_platform_data *pdata;
+
+ unsigned int length = 0, id = 0;
+ int hw_mod_name_len = 16;
+ char oh_name[hw_mod_name_len];
+ char *name = omap4-keypad;
+
+ length = snprintf(oh_name, hw_mod_name_len, keyboard);
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -EIO;
+ }
+
+ pdata = kzalloc(sizeof(struct matrix_keypad_platform_data), GFP_KERNEL);
+ if (!pdata) {
+ WARN(1, Keyboard pdata memory allocation failed\n);
+ return -ENOMEM;
+ }
+
+ pdata = sdp4430_keypad_data;
+
+ pdata-base = oh-_rt_va;
+ pdata-irq = oh-mpu_irqs[0].irq;
+ pdata-device_enable = omap_device_enable;
+ pdata-device_idle = omap_device_idle;
+ pdata-device_shutdown = omap_device_shutdown;
+
+ od = omap_device_build(name, id, oh, pdata,
+ sizeof(struct matrix_keypad_platform_data),
+ omap_keyboard_latency,
+
[RFC] [PATCH v2 4/4] OMAP4: Keyboard kernel configuration
From: Syed Rafiuddin rafiuddin.s...@ti.com Update OMAP4430 configuration to enable OMAP4 keyboard driver Signed-off-by: Abraham Arce x0066...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index d87a349..b7928d4 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -439,7 +439,8 @@ CONFIG_INPUT_EVDEV=y # # Input Device Drivers # -# CONFIG_INPUT_KEYBOARD is not set +CONFIG_INPUT_KEYBOARD=y +CONFIG_KEYBOARD_OMAP4=y # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thursday 13 May 2010, Matthew Garrett wrote: On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. If the interface is there for a long time, it's because we haven't come up with anything better. And if we haven't come up with anything better, the interface deserves to be there. Moreover, the interface is already in use out-of-tree and that usage is actually _growing_, so we have a growing number of out-of-tree drivers that aren't megrgeable for this very reason. I don't see any _realistic_ way of solving this problem other than merging the opportunistic suspend. If anyone sees one, and I mean _realistic_ and _practically_ _feasible_, please tell me. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
