Re: LDP support
On Sun, May 31, 2009 at 07:24:19PM -0500, Woodruff, Richard wrote: 6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable ARM errata 460075 - it solidly prevents the kernel booting on LDP. (it's taken many hours to debug that.) This is an r2p0 errata only. It's not in earlier versions or in later cores. Yes. Today there are only r1pX OMAP3s today. In the future there will be r3px also. That's something that TI may know, but it's almost impossible for developers to know because: (a) the OMAP3430 TRMs aren't available. (b) you have to reverse engineer the ARM ID register using the ARM Cortex A8 TRMs to find out that the 'variant' field describes the number after 'r' and the 'revision' field describes the number after the 'p', and then looking at the ID value reported by the kernel for the OMAP3430 in the LDP, you find that it's an undocumented r1p2 version. So it's all very well specifying that errata N applies to some random variants and revisions of the CPU, but that's insufficient for developers who'll be configuring the kernel. As said on linux-arm-kernel, we need the kernel to only apply these errata fixes to the CPUs which they are applicable to if enabled, rather than every CPU. I provided a patch to do this, and this enables LDP to boot with all errata config options enabled. -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3: PM: 2 new entries in SDRC table for Qimonda HYB18M512160AF-6
This patch adds 2 more entries for new SDRC clock rates
(16600 and 8300) in the sdrc params table for
Qimonda HYB18M512160AF-6 sdram part.
Without this CORE dvfs is broken on the 3430SDP as
omap2_sdrc_get_params() call in the dvfs sequence
always return 'rate not found'
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 22 ---
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
index 74a92c8..5b83076 100644
--- a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
+++ b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
@@ -20,34 +20,48 @@
/* XXX Using ARE = 0x1 (no autorefresh burst) -- can this be changed? */
static struct omap_sdrc_params hyb18m512160af6_sdrc_params[] = {
[0] = {
- .rate= 165941176,
+ .rate= 16600,
.actim_ctrla = 0x629db4c6,
.actim_ctrlb = 0x00012214,
.rfr_ctrl= 0x0004dc01,
.mr = 0x0032,
},
[1] = {
+ .rate= 165941176,
+ .actim_ctrla = 0x629db4c6,
+ .actim_ctrlb = 0x00012214,
+ .rfr_ctrl= 0x0004dc01,
+ .mr = 0x0032,
+ },
+ [2] = {
.rate= 1,
.actim_ctrla = 0x5219b485,
.actim_ctrlb = 0x00012210,
.rfr_ctrl= 0x0003de01,
.mr = 0x0032,
},
- [2] = {
+ [3] = {
+ .rate= 8300,
+ .actim_ctrla = 0x31512283,
+ .actim_ctrlb = 0x0001220a,
+ .rfr_ctrl= 0x00025501,
+ .mr = 0x0022,
+ },
+ [4] = {
.rate= 82970588,
.actim_ctrla = 0x31512283,
.actim_ctrlb = 0x0001220a,
.rfr_ctrl= 0x00025501,
.mr = 0x0022,
},
- [3] = {
+ [5] = {
.rate= ,
.actim_ctrla = 0x290d2243,
.actim_ctrlb = 0x00012208,
.rfr_ctrl= 0x0001d601,
.mr = 0x0022,
},
- [4] = {
+ [6] = {
.rate= 0
},
};
--
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
Re: Please help in adding ams-delta support to ASoC
Janusz Krzysztofik wrote:
So I am going to restart with checking if the original patch still works with
the latest kernel version supporting omap-alsa.
The original patch ported to linux-omap-2.6.27, the last omap release
with omap-alsa support, gives me a working sound driver on ams-delta.
Jarkko Nikula wrote:
Looks like McBSP is not getting bit-clock and frame-sync signals from
the codec. ...
Another possibility are the OMAP pins muxed for McBSP? I assume they
are if the bootloader is still the same but worth to find check was
previous kernel doing any runtime remuxing for those pins with
omap_cfg_reg calls.
Peter Ujfalusi wrote:
This means that the McBSP module is not transmitting/receiving any data.
Which suggests that the clocking is not working in your setup. Check the slave
master mode for the codec.
Also worth checking the PIN configuration for the McBSP1 module, just in case
it is correct.
My port of the original driver is still very generic. There are no mux
setups. It containes only two simple hardware pin setup calls that make
it working, those are invoked from two callback functions,
omap_alsa_codec_config.codec_clock_on() and
omap_alsa_codec_config.codec_clock_off(), as below:
---
int vc_clock_on(void)
{
if (clk_get_usecount(vc_mclk) 0) {
/* MCLK is already in use */
printk(KERN_WARNING
MCLK in use at %d Hz. We change it to %d Hz\n,
(uint) clk_get_rate(vc_mclk),
CODEC_CLOCK);
}
clk_enable(vc_mclk);
printk(KERN_DEBUG
MCLK = %d [%d], usecount = %d\n,
(uint) clk_get_rate(vc_mclk), CODEC_CLOCK,
clk_get_usecount(vc_mclk));
/* Now turn the audio on */
ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_NRESET |
AMS_DELTA_LATCH2_MODEM_CODEC,
AMS_DELTA_LATCH2_MODEM_NRESET);
return 0;
}
int vc_clock_off(void)
{
if (clk_get_usecount(vc_mclk) 0) {
if (clk_get_rate(vc_mclk) != CODEC_CLOCK) {
printk(KERN_WARNING
MCLK for audio should be %d Hz. But is
%d Hz\n,
(uint) clk_get_rate(vc_mclk),
CODEC_CLOCK);
}
clk_disable(vc_mclk);
}
ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
AMS_DELTA_LATCH2_MODEM_CODEC);
return 0;
}
...
static int __init snd_omap_alsa_vc_probe(struct platform_device *pdev)
{
...
struct omap_alsa_codec_config *codec_cfg;
...
codec_cfg-codec_clock_on = vc_clock_on;
codec_cfg-codec_clock_off = vc_clock_off;
...
}
static struct platform_driver omap_alsa_driver = {
.probe = snd_omap_alsa_vc_probe,
...
};
static int __init omap_alsa_vc_init(void)
{
int err;
err = platform_driver_register(omap_alsa_driver);
return err;
}
--
Jarkko Nikula wrote:
OMAP1510 doesn't support DMA chaining so there are few
cpu_is_omap1510() code snippets in sound/soc/omap/omap-pcm.c which I
think I have only simulated using OMAP2420.
To make the original driver work stable, I had to patch the omap-alsa
framework to restore the original way that lack of dma chaining problem
had been solved in the original patch (see below), so maybe there is a
similiar issue in the currect ASoC McBSP framework?
--
diff -uprN linux-2.6.27/sound/arm/omap/omap-alsa.c
linux-2.6.27-sound/sound/arm/omap/omap-alsa.c
--- linux-2.6.27/sound/arm/omap/omap-alsa.c 2009-05-30
21:27:09.0 +
+++ linux-2.6.27-sound/sound/arm/omap/omap-alsa.c 2009-05-30
22:12:12.0 +
@@ -52,6 +52,8 @@
#include mach/omap-alsa.h
#include omap-alsa-dma.h
+#include asm/mach-types.h
+
MODULE_AUTHOR(Mika Laitio);
MODULE_AUTHOR(Daniel Petrini);
MODULE_AUTHOR(David Cohen);
@@ -210,7 +212,7 @@ static int audio_start_dma_chain(struct
* irq from DMA after the first transfered/played buffer.
* (invocation of callback_omap_alsa_sound_dma() method).
*/
- if (cpu_is_omap1510())
+ if (cpu_is_omap1510() !machine_is_ams_delta())
omap_stop_alsa_sound_dma(s);
dma_start_pos = (dma_addr_t)runtime-dma_area + offset;
diff -uprN linux-2.6.27/sound/arm/omap/omap-alsa-dma.c
linux-2.6.27-sound/sound/arm/omap/omap-alsa-dma.c
--- linux-2.6.27/sound/arm/omap/omap-alsa-dma.c 2009-05-30
21:27:09.0 +
+++ linux-2.6.27-sound/sound/arm/omap/omap-alsa-dma.c 2009-05-30
22:12:12.0 +
@@ -70,6 +70,8 @@
#include asm/arch/omap-alsa.h
+#include asm/mach-types.h
+
#undef DEBUG
#define ERR(ARGS...) printk(KERN_ERR {%s}-ERROR: ,
Re: [PATCH 05/10] ARM: OMAP1: Make 770 LCD work
Andrew de Quincey adq_...@lidskialf.net writes:
Out of interest, what is the best practice way to pass platform
specific GPIOs around? There are a number of other n770 related
drivers I'm intending on cleaning up, several of which have GPIO
numbers hardcoded in them. Should these be passed in platform
structures, or is there something analogous to the clk_alias for
GPIOs?
I was told that platform structures are the preferred way. For wl12xx (a
wi-fi driver) I created a set_power function pointer which will control
the power gpio line:
27 struct wl12xx_platform_data {
28 void (*set_power)(bool enable);
29 };
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=blob;f=include/linux/spi/wl12xx.h;h=11430cab2aad71242946ebfc7c0ce778d8bf26a1;hb=HEAD
And the irq is configured in the board file and provided to wl12xx with
struct spi_device.irq. So wl12xx doesn't use gpio code at all, it's all
done in the board file.
Please comment if this isn't the correct way to do this.
--
Kalle Valo
--
To unsubscribe from this list: send the line unsubscribe 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: LDP support
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux Sent: Monday, June 01, 2009 2:45 AM On Sun, May 31, 2009 at 07:24:19PM -0500, Woodruff, Richard wrote: 6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable ARM errata 460075 - it solidly prevents the kernel booting on LDP. (it's taken many hours to debug that.) This is an r2p0 errata only. It's not in earlier versions or in later cores. Yes. Today there are only r1pX OMAP3s today. In the future there will be r3px also. That's something that TI may know, but it's almost impossible for developers to know because: (a) the OMAP3430 TRMs aren't available. Yes it is publicly available in a few forms. Using google I was just able to find a few references. For public 3430 look here: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf The 35xx one is out there also (mostly the same) and easier to find. The public TRM above has the ARM revision/patch version documented in section 3.1.2. The ARM core is r1p3 in OMAP3430-ES3.1 and r1p7 for OMAP3430-ES3.1.1. Last time I looked in an ID register it seemed ok but I had inside information and may have missed something. Your use of a run time check seemed good. Thanks, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: LDP support
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux Sent: Monday, June 01, 2009 2:45 AM That's something that TI may know, but it's almost impossible for developers to know because: BTW, yes, the forest of TRMs for OMAP3 can be hard to follow. There are public and private versions and many addendums. There are also 35xx vs. 34xx versions. In the end most of the necessary information is publically available. Sites like beagleboard and zoom try to make more of this digestible. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LDP support
* Russell King - ARM Linux li...@arm.linux.org.uk [090531 14:25]: On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [090428 15:07]: Tony, et.al., Any ideas when more LDP support will be pushed into mainline (such as the framebuffer support)? I'll be looking at the board-*.c patches for the next merge window hopefully this week or next week. Looks like LDP keyboard, touchscreen RTC are pretty much ready to go. Then the MMC has some regulator updates, but AFAIK the MMC should work OK already. For the framebuffer, Imre and Tomi know the status the best, so I've added them to Cc. Imre has been meaning to send a bunch of drivers/video/omap changes to the fbdev list for a while now and LDP framebuffer may depend on those. Imre, any news on the status of sending the fb patches upstream? Then there are the upcoming DSS patches from Tomi, but those still need some work before they're ready to go. Okay, now that I've merged your tree, we've moved a few steps forward but a couple of steps backward with LDP support: 1. LDP LCD platform device added 2. GPIO keyboard platform data added 3. TWL4030 keyboard platform data added 4. TSC2046 touchscreen platform data added 5. MMC has regressed - no sign of the driver initializing, not even an error message from it, so I can't boot to check what the status of these are. Do you have CONFIG_REGULATOR set in your .config? That seems to be missing from arch/arm/configs/omap_ldp_defconfig. 6. do ___NOT___ (underscored in triplicate and 500ft high letters) enable ARM errata 460075 - it solidly prevents the kernel booting on LDP. (it's taken many hours to debug that.) However, things that still seem to be missing: 1. GPIO keyboard (presumably) needs to be enabled in omap_ldp_defconfig Anybody with an LDP care to update the omap_ldp_defconfig? No LDP here. 2. No TWL4030 keyboard driver merged (not even in linux-next) 3. No LDP LCD driver merged 4. No OMAP3 video driver For 3 4, I know Imre has the patches ready to go.. Imre, have they been posted to the fb list? 5. No sound? This could be pretty easy now with the ASoC driver, anybody seen a driver fro this? Any ideas what's happening with these? Will they make the next merge window (which is possibly about a week away) - I guess not. :( Well sounds like the defconfig fixes, keyboard, and fb updates still have a chance to get in. 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: LDP support
On Mon, Jun 01, 2009 at 09:00:33AM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [090531 14:25]: Okay, now that I've merged your tree, we've moved a few steps forward but a couple of steps backward with LDP support: 1. LDP LCD platform device added 2. GPIO keyboard platform data added 3. TWL4030 keyboard platform data added 4. TSC2046 touchscreen platform data added 5. MMC has regressed - no sign of the driver initializing, not even an error message from it, so I can't boot to check what the status of these are. Do you have CONFIG_REGULATOR set in your .config? That seems to be missing from arch/arm/configs/omap_ldp_defconfig. Yes, that fixes it. I think it would be a good thing that a KERN_ERR message is displayed to cover this case, since it currently fails completely silently. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP clock/powerdomain/SDRC patches for post-2.6.30
* Paul Walmsley p...@pwsan.com [090526 15:27]: Hello Russell, here is the next set of OMAP clock patches for review for the post-2.6.30 merge window. They apply on top of the previous set (OMAP clock/SDRC patches on v2.6.30-rc5). If you're happy with these patches, Tony will queue them up into his for-next branch. Looks like Russell now has all the omap for-next merged to his devel branch. Only this series is missing and the omap4 SMP patches. Paul, can you please reply with the output from git request-pull for Russell to pull these in too? AFAIK, there should not be any need to rebase this series, it should merge clean from v2.6.30-rc7 to Russell's devel branch. Regards, Tony This series completes basic support for OMAP3 CORE DVFS. A few other minor bugs are fixed by the off-by-one patch and the GPIO debounce clock patch. regards, - Paul --- Paul Walmsley (8): OMAP3 clock: GPIO de-bounce clocks don't affect module idle state OMAP3 SDRC: set FIXEDDELAY when disabling SDRC DLL OMAP3 SRAM: convert SRAM code to use macros rather than magic numbers OMAP3 SRAM: add more comments on the SRAM code OMAP3 clock/SDRC: program SDRC_MR register during SDRC clock change OMAP3 clock: add a short delay when lowering CORE clk rate OMAP3 clock: initialize SDRC timings at kernel start OMAP3 clock: remove wait for DPLL3 M2 clock to stabilize Roel Kluin (1): OMAP2 clock/powerdomain: off by 1 error in loop timeout comparisons Tero Kristo (1): OMAP3: Add support for DPLL3 divisor values higher than 2 arch/arm/mach-omap2/clock.c|2 arch/arm/mach-omap2/clock34xx.c| 42 -- arch/arm/mach-omap2/clock34xx.h| 12 +-- arch/arm/mach-omap2/io.c | 38 + arch/arm/mach-omap2/powerdomain.c |2 arch/arm/mach-omap2/sram34xx.S | 129 +--- arch/arm/plat-omap/include/mach/sram.h |6 + arch/arm/plat-omap/sram.c |8 +- 8 files changed, 171 insertions(+), 68 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP clock/powerdomain/SDRC patches for post-2.6.30
On Mon, Jun 01, 2009 at 09:56:24AM -0700, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [090526 15:27]: Hello Russell, here is the next set of OMAP clock patches for review for the post-2.6.30 merge window. They apply on top of the previous set (OMAP clock/SDRC patches on v2.6.30-rc5). If you're happy with these patches, Tony will queue them up into his for-next branch. Looks like Russell now has all the omap for-next merged to his devel branch. Only this series is missing and the omap4 SMP patches. This series I've avoided looking at due to lack of time. I only just got around to sorting through your patches from the last two weeks last Thursday/Friday, and I've spent Sunday evening and today boot testing and debugging what's been merged on my LDP platform. It'll be a week or so before I look at OMAP again. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP clock/powerdomain/SDRC patches for post-2.6.30
* Russell King - ARM Linux li...@arm.linux.org.uk [090601 10:09]: On Mon, Jun 01, 2009 at 09:56:24AM -0700, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [090526 15:27]: Hello Russell, here is the next set of OMAP clock patches for review for the post-2.6.30 merge window. They apply on top of the previous set (OMAP clock/SDRC patches on v2.6.30-rc5). If you're happy with these patches, Tony will queue them up into his for-next branch. Looks like Russell now has all the omap for-next merged to his devel branch. Only this series is missing and the omap4 SMP patches. This series I've avoided looking at due to lack of time. I only just got around to sorting through your patches from the last two weeks last Thursday/Friday, and I've spent Sunday evening and today boot testing and debugging what's been merged on my LDP platform. Yeah it's been busy with omap patches again. The good news is that after 2.6.30 we should be able to have linux-omap tree just contain patches for the upcoming merge windows! It'll be a week or so before I look at OMAP again. Thanks for the update. Sounds like we still have some time to deal with the remaining two patch sets. 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: DSS2: SYNC Lost error on mirroring enabled
Hi Tomi, I managed to fix the Mirroring UNDERFLOW error on LDP board. It was pixel clock issue. I also emailed you patch supporting LDP DSS2, could you comment on it. Regards, Subbu From: Tomi Valkeinen [tomi.valkei...@nokia.com] Sent: Friday, May 29, 2009 7:20 AM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; Castaneda Gonzalez, Axel; Mande, Nikhil Subject: RE: DSS2: SYNC Lost error on mirroring enabled Hi, On Fri, 2009-05-29 at 14:06 +0200, ext Venkatesh, Subbu wrote: Hello Tomi, I have no problem with the Roatation using VRFB. Curretnly the issue is with the Mirroring. Using VRFB for mirroring has no effect as I see in the omapfb-main.c, if Rotation type is VRFB, then mirror=0. So I cannot use mirroring at all. I meant that VRFB is used also for mirroring, and so you need VRFB. But true, VRFB mirroring is currently disabled, and doesn't seem to work. Tomi Regards, Subbu From: Tomi Valkeinen [tomi.valkei...@nokia.com] Sent: Friday, May 29, 2009 1:51 AM To: Venkatesh, Subbu Cc: linux-omap@vger.kernel.org; Shah, Hardik; Castaneda Gonzalez, Axel; Mande, Nikhil Subject: Re: DSS2: SYNC Lost error on mirroring enabled On Fri, 2009-05-29 at 03:32 +0200, ext Venkatesh, Subbu wrote: Hi, I am getting SYNC LOSTerror on OMAP development board ( LDP ), this happens when I enable mirroring by a command #echo 1 /sys/class/graphics/fb0/mirror In brief, recently I ported board related funtions to support both LCD and TV displays on Omap LDP, mirroring works on TV but not LCD. Attached log gives more details. Any inputs are appreciated. You need to use VRFB rotation, DMA rotation is only meant for SRAM framebuffers. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help in adding ams-delta support to ASoC
On Mon, 01 Jun 2009 14:41:59 +0200 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: The original patch ported to linux-omap-2.6.27, the last omap release with omap-alsa support, gives me a working sound driver on ams-delta. Ok, good to know. To make the original driver work stable, I had to patch the omap-alsa framework to restore the original way that lack of dma chaining problem had been solved in the original patch (see below), so maybe there is a similiar issue in the currect ASoC McBSP framework? Is the older implementation working at commit d8376cc482b241701f7606c81ad578b90853e175 in linux-omap, i.e. last commit before their removal? What I see at quick look from the older implementation that it is doing somewhat similar way the DMA transfer and workaround for 1510 than current ASoC except that now the DMA parameters are not reprogrammed between the restarted transfers. I don't know if 1510 requires it? My asoc based patch is also very generic and contains no more that the same two ams_delta_latch2_write() hardware related operations, called from inside snd_soc_dai_link.ops.startup() and snd_soc_dai_link.ops.shutdown() callback functions: One thing worth to try would be try to use exactly same McBSP registers for omap_mcbsp_config in omap_mcbsp_dai_hw_params than used before for ams delta. Sorry, have to cut my answer now here. I'll get back tomorrow. -- Jarkko My conclusuions so far: 1. If the new OMAP McBSP ASoC framework provides all the functionality of the depreciated OMAP Alsa under a different API, the only reason of my driver not working I can imagine is that I have put these two lines of hardware related code in wrong places. If this is the case, could someone please point me into the right direction? 2. Maybe the original ams-delta sound driver should not in theory work as is? Maybe Mark Underwood was just lucky enough to get it working without any real hardware setup? 3. Otherwise, there must be a significant difference in (alsa) MsBSP handling code that I am not able to identify and resolve myself. I can only say that I have seen much more mcbsp_...() stuff in the old omap-alsa framework than in the current one. The differece can be significant for OMAP15XX, or OMAP5910, or even ams-delta only. 4. Base (not alsa related) McBSP framework did not change since 2.6.16 (the original patch base) up to 2.6.27 in a way that could break the original patch. If my problem was related to base McBSP handling, changes should be looked for after 2.6.27, if any. Jarkko Nikula wrote: It would be nice to get this working since it would be the first OMAP5910 == OMAP1510 based machine driver. I am personally interested in this, as I have bought two E3's recently in hope I can make use of them as IP phones. But for now, I have no idea what else I could try. I have noticed that Andrew de Quincey is going to fix sound on Nokia 770, maybe he finds something related. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] Patch: Fix N770 MMC support
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): ed7f50cfdf4f40f6f153ea0623c86bb2fa6cb7ad PatchWorks http://patchwork.kernel.org/patch/25537/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=ed7f50cfdf4f40f6f153ea0623c86bb2fa6cb7ad -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] Patch: Fix N770 brf6150 bluetooth driver
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): c9023d6fa335c5dc49d67c142a1bd7887782 PatchWorks http://patchwork.kernel.org/patch/25540/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=c9023d6fa335c5dc49d67c142a1bd7887782 -- To unsubscribe from this list: send the line unsubscribe 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] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
This patch adds irq_enable and irq_disable for OMAP GPIO IRQ chip, and
also only enable WAKEUPEN
When GPIO edge detection is enabled, also clear the gpio event
triggering configurations to avoid
Pending interrupt status which is generated regardless of the IRQEN and
WKUPEN bit, the pending
IRQ status may prevent GPIO module acknowledge IDLE request and prevent
PER and thus RETENTION.
This is only applied for OMAP2/3 GPIO IRQs.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/gpio.c | 44
++--
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index bd04b40..19e0461 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -581,7 +581,7 @@ void omap_set_gpio_debounce_time(int gpio, int
enc_time)
EXPORT_SYMBOL(omap_set_gpio_debounce_time);
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
-static inline void set_24xx_gpio_triggering(struct gpio_bank *bank, int
gpio,
+static void set_24xx_gpio_triggering(struct gpio_bank *bank, int gpio,
int trigger)
{
void __iomem *base = bank-base;
@@ -597,7 +597,12 @@ static inline void set_24xx_gpio_triggering(struct
gpio_bank *bank, int gpio,
trigger IRQ_TYPE_EDGE_FALLING);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
- if (trigger != 0)
+ /*
+* GPIO wakeup request can only be generated on edge
+* transitions, see OMAP34xx_ES3.1_TRM_V_Q G25.5.3.1
+* wake-up request note for detail
+*/
+ if ((trigger IRQ_TYPE_EDGE_BOTH) != 0)
__raw_writel(1 gpio, bank-base
+ OMAP24XX_GPIO_SETWKUENA);
else
@@ -1133,6 +1138,39 @@ static void gpio_ack_irq(unsigned int irq)
_clear_gpio_irqstatus(bank, gpio);
}
+static void gpio_enable_irq(unsigned int irq)
+{
+ unsigned int gpio = irq - IH_GPIO_BASE;
+ struct gpio_bank *bank = get_irq_chip_data(irq);
+ int trigger = irq_desc[irq].status IRQ_TYPE_SENSE_MASK;
+
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+ set_24xx_gpio_triggering(bank, get_gpio_index(gpio), trigger);
+#endif
+ _set_gpio_irqenable(bank, gpio, 1);
+}
+
+static void gpio_disable_irq(unsigned int irq)
+{
+ unsigned int gpio = irq - IH_GPIO_BASE;
+ struct gpio_bank *bank = get_irq_chip_data(irq);
+
+ _set_gpio_irqenable(bank, gpio, 0);
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+ /*
+* Clear the event detect setting and IRQ status to prevent
+* IRQ staus been set or pending there While IRQ is disabled,
+* otherwise GPIO module will not acknowledge the IDLE request
+* from PER power domain, this may prevent System wide retention
+* See OMAP34xx_ES3.1_TRM_V_Q G25.5.3.1 GPIO interrupt and
wakeup
+* enable note for detail
+*/
+ set_24xx_gpio_triggering(bank, get_gpio_index(gpio),
IRQ_TYPE_NONE);
+ _clear_gpio_irqstatus(bank, gpio);
+#endif
+
+}
+
static void gpio_mask_irq(unsigned int irq)
{
unsigned int gpio = irq - IH_GPIO_BASE;
@@ -1160,6 +1198,8 @@ static void gpio_unmask_irq(unsigned int irq)
static struct irq_chip gpio_irq_chip = {
.name = GPIO,
.shutdown = gpio_irq_shutdown,
+ .enable = gpio_enable_irq,
+ .disable= gpio_disable_irq,
.ack= gpio_ack_irq,
.mask = gpio_mask_irq,
.unmask = gpio_unmask_irq,
--
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] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable
Resend because of the content format issues in last mail---sorry for
inconvenience.
This patch adds irq_enable and irq_disable for OMAP GPIO IRQ chip, and
also only enable WAKEUPEN When GPIO edge detection is enabled,
also clear the gpio event triggering configurations to avoid Pending
interrupt status which is generated regardless of the IRQEN and WKUPEN
bit,
the pending IRQ status may prevent GPIO module acknowledge IDLE request
and prevent PER and thus CORE RETENTION.
This is only applied for OMAP2/3 GPIO IRQs.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/gpio.c | 44
++--
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index bd04b40..19e0461 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -581,7 +581,7 @@ void omap_set_gpio_debounce_time(int gpio, int
enc_time)
EXPORT_SYMBOL(omap_set_gpio_debounce_time);
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
-static inline void set_24xx_gpio_triggering(struct gpio_bank *bank, int
gpio,
+static void set_24xx_gpio_triggering(struct gpio_bank *bank, int gpio,
int trigger)
{
void __iomem *base = bank-base;
@@ -597,7 +597,12 @@ static inline void set_24xx_gpio_triggering(struct
gpio_bank *bank, int gpio,
trigger IRQ_TYPE_EDGE_FALLING);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
- if (trigger != 0)
+ /*
+* GPIO wakeup request can only be generated on edge
+* transitions, see OMAP34xx_ES3.1_TRM_V_Q G25.5.3.1
+* wake-up request note for detail
+*/
+ if ((trigger IRQ_TYPE_EDGE_BOTH) != 0)
__raw_writel(1 gpio, bank-base
+ OMAP24XX_GPIO_SETWKUENA);
else
@@ -1133,6 +1138,39 @@ static void gpio_ack_irq(unsigned int irq)
_clear_gpio_irqstatus(bank, gpio);
}
+static void gpio_enable_irq(unsigned int irq)
+{
+ unsigned int gpio = irq - IH_GPIO_BASE;
+ struct gpio_bank *bank = get_irq_chip_data(irq);
+ int trigger = irq_desc[irq].status IRQ_TYPE_SENSE_MASK;
+
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+ set_24xx_gpio_triggering(bank, get_gpio_index(gpio), trigger);
+#endif
+ _set_gpio_irqenable(bank, gpio, 1);
+}
+
+static void gpio_disable_irq(unsigned int irq)
+{
+ unsigned int gpio = irq - IH_GPIO_BASE;
+ struct gpio_bank *bank = get_irq_chip_data(irq);
+
+ _set_gpio_irqenable(bank, gpio, 0);
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+ /*
+* Clear the event detect setting and IRQ status to prevent
+* IRQ staus been set or pending there While IRQ is disabled,
+* otherwise GPIO module will not acknowledge the IDLE request
+* from PER power domain, this may prevent System wide retention
+* See OMAP34xx_ES3.1_TRM_V_Q G25.5.3.1 GPIO interrupt and
wakeup
+* enable note for detail
+*/
+ set_24xx_gpio_triggering(bank, get_gpio_index(gpio),
IRQ_TYPE_NONE);
+ _clear_gpio_irqstatus(bank, gpio);
+#endif
+
+}
+
static void gpio_mask_irq(unsigned int irq)
{
unsigned int gpio = irq - IH_GPIO_BASE;
@@ -1160,6 +1198,8 @@ static void gpio_unmask_irq(unsigned int irq)
static struct irq_chip gpio_irq_chip = {
.name = GPIO,
.shutdown = gpio_irq_shutdown,
+ .enable = gpio_enable_irq,
+ .disable= gpio_disable_irq,
.ack= gpio_ack_irq,
.mask = gpio_mask_irq,
.unmask = gpio_unmask_irq,
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org More majordomo info
at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3 Overo: add EXPORT_SYMBOLs for Overo ASoC audio to be built as a module.
I'm pretty new to kernel development, so I don't know any potential
problems with doing this, but without this, audio/ASoC support must be
built into the kernel (modpost fails when trying to build as modules),
whereas with this patch, it can be built and used as a module.
Comments?
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 5f3aad9..aa3d123 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -46,6 +46,7 @@ u32 omap_ctrl_readl(u16 offset)
{
return __raw_readl(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readl);
void omap_ctrl_writeb(u8 val, u16 offset)
{
@@ -61,4 +62,5 @@ void omap_ctrl_writel(u32 val, u16 offset)
{
__raw_writel(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writel);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
