Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
From: ext Kanigeri, Hari h-kanige...@ti.com
Subject: RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
Date: Mon, 8 Jun 2009 22:49:21 +0200
Hi Doyu-san,
Regarding
http://marc.info/?l=linux-omapm=124201773423892w=2
I think that the first one should be merged into d.o-z.org now, but
for the second one about 128 byte alignment. let me know your
thought/plan on it.
-- I think you sent this patch as a probable fix for the slab
corruption that was observed in Bridge driver, but then we found
that slab corruption was due to some other issue in Bridge driver
and not due to the cache alignment.
Irrespective of above point, I think it is good to enforce the cache
alignment check, but I think the check should be in Proc Map
function and to start with the check should be under a flag so as
not to affect some MM applications that use padding to get over the
alignment issue.
I think that having configurable option may be reasonable practically,
at the moment.
But how about the longer term solution? Do you have any plan on how to
deal with this? (ex: TI's OMX layer and some other userland client) Do
you continue the userland buffer padding solution for the futer
release?
Thank you,
Best regards,
Hari
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hiroshi DOYU
Sent: Monday, June 08, 2009 6:34 AM
To: Ramirez Luna, Omar
Cc: ameya.pala...@nokia.com; linux-omap@vger.kernel.org;
felipe.contre...@gmail.com
Subject: Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
From: ext Ramirez Luna, Omar omar.rami...@ti.com
Subject: RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
Date: Mon, 8 Jun 2009 08:49:03 +0200
From: Ameya Palande [mailto:ameya.pala...@nokia.com]
Subject: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
From: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/rmgr/drv_interface.c |2 +-
drivers/dsp/bridge/rmgr/drv_interface.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index c3d8a02..f41e153 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -665,7 +665,7 @@ static int bridge_release(struct inode *ip, struct
file *filp)
}
/* This function provides IO interface to the bridge driver. */
-static int bridge_ioctl(struct file *filp, unsigned int code,
+static long bridge_ioctl(struct file *filp, unsigned int code,
unsigned long args)
{
int status;
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.h
b/drivers/dsp/bridge/rmgr/drv_interface.h
index 3e77ed0..dc49210 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.h
+++ b/drivers/dsp/bridge/rmgr/drv_interface.h
@@ -34,7 +34,7 @@ static int __init bridge_init(void); /* Initialize
bridge */
static void __exit bridge_exit(void); /* Opposite of initialize */
static int bridge_open(struct inode *, struct file *); /* Open */
static int bridge_release(struct inode *, struct file *); /*
Release */
-static int bridge_ioctl(struct file *, unsigned int,
+static long bridge_ioctl(struct file *, unsigned int,
unsigned long);
static int bridge_mmap(struct file *filp, struct vm_area_struct *vma);
#endif /* ifndef _DRV_INTERFACE_H_ */
--
1.6.2.4
Pushed to bridge tree on dev.omapzoom.org
Thanks. Also there still seems to remain 2 patches:
http://marc.info/?l=linux-omapm=124201773423895w=2
http://marc.info/?l=linux-omapm=124201773423892w=2
I think that the first one should be merged into d.o-z.org now, but
for the second one about 128 byte alignment. let me know your
thought/plan on it.
- omar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
Hello Russell, On Tue, 26 May 2009, Paul Walmsley wrote: 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. 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. Any comments on these patches? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Please help in adding ams-delta support to ASoC
Hello Janusz, On Saturday 06 June 2009 20:42:12 ext Janusz Krzysztofik wrote: I'm not sure how that could happen, but I was wrong with some of those figures. After looking at the scope several more times I can only confirm that master clock really runs at 2MHz (0,5µs period). Frame sync is rather closer to 8kHz (~125µs period) than previously estimated 10kHz, with the same symmetric (50% fill) shape as before. But bit clock is very different from what I have seen before. It runs at 2MHz in 9µs long packets (18 periods), those are repeated every half period of frame sync (~62µs / 16kHz), ie every frame sync edge, both rising and falling. There is also a signal present on codec data output: 4µs long packets (8 bits each?) every ~62µs (16 kHz). I'm kind of bad at visualizing things, is it possible to put somewhere the screenshoot of the scope showing at least one sample? Is it possible that the codec speeks I2S, with 8-bit word, 1 word per frame, 2 channels at 8kHz each? Or 1 channel at 16 kHz? From what I can read in modem documentation, this should rather be one 8-bit channel at 8kHz. Anyway, can the transmission format I have seen ont the oscilloscope be matched against any format that mcbsp can be set with current code? I have been looking for clues around the net, and it seams that the codec in question has stereo 16 bit format. I'm still far from understanding mcbsp, but I wonder what happens if the bit clock stops ater 18th bit while maybe mcbsp expects more. Perhaps this is the cause of dma interrupts not being generated? Without actual OMAP1510 HW it is really hard to tell what can be the problem. What I would do, if I had a HW: 1) See if the DMA actually was running and it is 'just' about the missing interrupt: --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -193,11 +193,15 @@ static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd) case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: prtd-period_index = 0; omap_start_dma(prtd-dma_ch); + printk(omap_pcm_trigger START: DMA pointer at 0x%08x\n, + (unsigned)omap_get_dma_src_pos(prtd-dma_ch)); break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + printk(omap_pcm_trigger STOP: DMA pointer at 0x%08x\n, + (unsigned)omap_get_dma_src_pos(prtd-dma_ch)); prtd-period_index = -1; omap_stop_dma(prtd-dma_ch); break; Than start a playback, and stop it with CTRL+C, see if the two pointers are different... 2) I would I think try to port the 2.6.28 pure ALSA version to the head of l- o, with minimal (only the needed) changes and see if it is still working. I know, this is a long shot, but at least we can be sure, that the problem is in the ASoC McBSP/DMA integration or it is something else. Meanwhile I'll try to locate one OMAP1510 based board to try to help with this issue. -- Péter -- 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] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings suspend/resume)
Hi Jean,
On Mon, 8 Jun 2009, Jean Pihet wrote:
Here is the updated patch that fixes the Overo build as well.
Can you check it?
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 9eae608..50902d4 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -45,6 +45,7 @@
#include mach/gpmc.h
#include mach/hardware.h
#include mach/nand.h
+#include mach/mux.h
#include mach/usb.h
#include sdram-micron-mt46h32m32lf-6.h
@@ -355,7 +356,9 @@ static int __init overo_i2c_init(void)
static void __init overo_init_irq(void)
{
- omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL, NULL, NULL);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
+ mt46h32m32lf6_sdrc_params,
+ NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
}
@@ -391,6 +394,10 @@ static void __init overo_init(void)
overo_init_smsc911x();
overo_ads7846_init();
+ /* Ensure SDRC pins are mux'd for self-refresh */
+ omap_cfg_reg(H16_34XX_SDRC_CKE0);
+ omap_cfg_reg(H17_34XX_SDRC_CKE1);
+
if ((gpio_request(OVERO_GPIO_W2W_NRESET,
OVERO_GPIO_W2W_NRESET) == 0)
(gpio_direction_output(OVERO_GPIO_W2W_NRESET, 1) == 0)) {
These changes look fine to me based on a quick look. Haven't tried
building it.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 08 June, 2009 20:24
To: Jean Pihet
Cc: Paul Walmsley; Kristo Tero (Nokia-D/Tampere); linux-omap
Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects
Jean Pihet jpi...@mvista.com writes:
On Monday 08 June 2009 16:59:36 Kevin Hilman wrote:
Jean Pihet jpi...@mvista.com writes:
Paul,
Here is the updated patch that fixes the Overo build as well.
Can you check it?
Kevin, can you push it if it is correct?
Can you run it through checkpatch, fix the errors and also merge
Tero's
RX51 patch if it looks good to you.
Ok. I will check. The cause might be the mailer.
I think we need the omap_cfg_reg calls in the RX51 board
file as well,
even if the bootloader has the mux setting already right. That way a
warning will be issued in case of a faulty bootloader. Do you agree?
I agree.
Well, this is ok for me too as it does not really change anything. I will voice
my opinion here though. :)
I find it somewhat weird that we take care of two pads in this fashion out of
~350 or so, where in most cases we just assume that the pads are configured
properly by the boot loader. Should we do the same for every pad? Does the
kernel even boot if the CKE signals are configured incorrectly? I would guess
the boot loader will fail to load the kernel image into SDRAM in that case.
-Tero
Kevin
Below are the checkpatch errors I get: looks lik your mailer is
probably wrapping the patch and there is also one error to fix.
Kevin
Regards,
Jean
ERROR: patch seems to be corrupt (line wrapped?)
#306: FILE: arch/arm/mach-omap2/clock34xx.c:477:
unsigned long rate)
ERROR: trailing whitespace
#494: FILE: arch/arm/mach-omap2/sdrc.c:128:
+ * @sdrc_cs[01]: pointers to a null-terminated list of struct $
total: 2 errors, 0 warnings, 648 lines checked
Your patch has style problems, please review. If any of
these errors
are false positives report them to the maintainer, see
CHECKPATCH in
MAINTAINERS.
Regards,
Jean
From ebe57354b0de059e1f042e0c488f761853f0 Mon Sep 17 00:00:00
2001
From: Jean Pihet jpi...@mvista.com
Date: Fri, 5 Jun 2009 17:19:00 +0200
Subject: OMAP3: add support for 2 SDRAM chip selects
Some boards (Beagle Cx, Overo) have 2 SDRAM parts
connected to the
SDRC.
This patch adds the following:
- ensure that the CKE signals mux settings are correct
- add a new argument of type omap_sdrc_params struct* to
omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
- adapted the OMAP boards files to the new prototype of
omap2_init_common_hw. Only Beagle and Overo are using the 2 CS'es
- adapt the sram sleep code to configure the SDRC for the 2nd CS
Note: If the 2nd param to omap2_init_common_hw is NULL, then the
parameters are not programmed into the SDRC CS1 registers
Tested on 3430 SDP and Beagleboard rev C2 and B5, with
suspend/resume and frequency changes (cpufreq).
Thanks to Paul Walmsley and Kevin Hilman for the suggestions and
code reviews.
Signed-off-by: Jean Pihet jpi...@mvista.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |6 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-n800.c |2 +-
arch/arm/mach-omap2/board-omap2evm.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c | 11 ++-
arch/arm/mach-omap2/board-omap3evm.c |6 +-
arch/arm/mach-omap2/board-omap3pandora.c |3 +-
arch/arm/mach-omap2/board-overo.c|9 ++-
arch/arm/mach-omap2/board-rx51.c |6 +-
arch/arm/mach-omap2/clock34xx.c | 37 ++--
arch/arm/mach-omap2/io.c |5 +-
arch/arm/mach-omap2/mux.c|6 ++
arch/arm/mach-omap2/sdrc.c | 63 +-
arch/arm/mach-omap2/sram34xx.S | 137
+++---
arch/arm/plat-omap/include/mach/io.h |3 +-
arch/arm/plat-omap/include/mach/mux.h|4 +
arch/arm/plat-omap/include/mach/sdrc.h |8 +-
arch/arm/plat-omap/include/mach/sram.h | 23 +++--
arch/arm/plat-omap/sram.c| 34 +---
23 files changed, 267 insertions(+), 108 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index aa5df72..4cb7bc5 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -322,7 +322,7 @@ out:
static void __init omap_2430sdp_init_irq(void) {
- omap2_init_common_hw(NULL);
+ omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
sdp2430_init_smc91x();
diff --git
Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects
On Tuesday 09 June 2009 10:14:58 tero.kri...@nokia.com wrote: -Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 08 June, 2009 20:24 To: Jean Pihet Cc: Paul Walmsley; Kristo Tero (Nokia-D/Tampere); linux-omap Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects Jean Pihet jpi...@mvista.com writes: On Monday 08 June 2009 16:59:36 Kevin Hilman wrote: Jean Pihet jpi...@mvista.com writes: Paul, Here is the updated patch that fixes the Overo build as well. Can you check it? Kevin, can you push it if it is correct? Can you run it through checkpatch, fix the errors and also merge Tero's RX51 patch if it looks good to you. Ok. I will check. The cause might be the mailer. I think we need the omap_cfg_reg calls in the RX51 board file as well, even if the bootloader has the mux setting already right. That way a warning will be issued in case of a faulty bootloader. Do you agree? I agree. Well, this is ok for me too as it does not really change anything. I will voice my opinion here though. :) I find it somewhat weird that we take care of two pads in this fashion out of ~350 or so, where in most cases we just assume that the pads are configured properly by the boot loader. Should we do the same for every pad? Got your point. This omap_cfg_reg throws a warning if the pad is incorrectly configured. The goal is to better track the problem in case of a wrong/older bootloader. In the ideal world the bootloader and kernel should match and do it all right! Does the kernel even boot if the CKE signals are configured incorrectly? I would guess the boot loader will fail to load the kernel image into SDRAM in that case. The kernel boots fine in that case, only the SDRAM contents are not preserved when going to low power mode. -Tero -- 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] OMAP3: add support for 2 SDRAM chip selects
-Original Message- From: ext Jean Pihet [mailto:jpi...@mvista.com] Sent: 09 June, 2009 11:24 To: Kristo Tero (Nokia-D/Tampere) Cc: khil...@deeprootsystems.com; p...@pwsan.com; linux-omap@vger.kernel.org Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects On Tuesday 09 June 2009 10:14:58 tero.kri...@nokia.com wrote: -Original Message- From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: 08 June, 2009 20:24 To: Jean Pihet Cc: Paul Walmsley; Kristo Tero (Nokia-D/Tampere); linux-omap Subject: Re: [RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects Jean Pihet jpi...@mvista.com writes: On Monday 08 June 2009 16:59:36 Kevin Hilman wrote: Jean Pihet jpi...@mvista.com writes: Paul, Here is the updated patch that fixes the Overo build as well. Can you check it? Kevin, can you push it if it is correct? Can you run it through checkpatch, fix the errors and also merge Tero's RX51 patch if it looks good to you. Ok. I will check. The cause might be the mailer. I think we need the omap_cfg_reg calls in the RX51 board file as well, even if the bootloader has the mux setting already right. That way a warning will be issued in case of a faulty bootloader. Do you agree? I agree. Well, this is ok for me too as it does not really change anything. I will voice my opinion here though. :) I find it somewhat weird that we take care of two pads in this fashion out of ~350 or so, where in most cases we just assume that the pads are configured properly by the boot loader. Should we do the same for every pad? Got your point. This omap_cfg_reg throws a warning if the pad is incorrectly configured. The goal is to better track the problem in case of a wrong/older bootloader. In the ideal world the bootloader and kernel should match and do it all right! Does the kernel even boot if the CKE signals are configured incorrectly? I would guess the boot loader will fail to load the kernel image into SDRAM in that case. The kernel boots fine in that case, only the SDRAM contents are not preserved when going to low power mode. Ok, in this case it sounds ok to me also as it might generate hard to track bugs. -Tero -- 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: Compiler wanrning fix for unlocked_ioctl
On Tue, Jun 9, 2009 at 4:18 AM, Kanigeri, Harih-kanige...@ti.com wrote: I agree, the check should be in proc map, and should be optional. However, I would prefer it to be an all-or-nothing option, how about in kconfig? -- One other way is we can use a bit mask in map attributes argument in DSP Proc Map function to enforce the check on the buffer. What are the reasons as why you want to make it all-or-nothing option ? The objective is to be more strict to give less power to user-space to screw up the system, an argument in proc map still lets user-space to screw up. -- 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] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
On Tue, Jun 9, 2009 at 10:02 AM, Hiroshi DOYUhiroshi.d...@nokia.com wrote: From: ext Kanigeri, Hari h-kanige...@ti.com Subject: RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl Date: Mon, 8 Jun 2009 22:49:21 +0200 Hi Doyu-san, Regarding http://marc.info/?l=linux-omapm=124201773423892w=2 I think that the first one should be merged into d.o-z.org now, but for the second one about 128 byte alignment. let me know your thought/plan on it. -- I think you sent this patch as a probable fix for the slab corruption that was observed in Bridge driver, but then we found that slab corruption was due to some other issue in Bridge driver and not due to the cache alignment. Irrespective of above point, I think it is good to enforce the cache alignment check, but I think the check should be in Proc Map function and to start with the check should be under a flag so as not to affect some MM applications that use padding to get over the alignment issue. I think that having configurable option may be reasonable practically, at the moment. But how about the longer term solution? Do you have any plan on how to deal with this? (ex: TI's OMX layer and some other userland client) Do you continue the userland buffer padding solution for the futer release? I don't know about TI's OMX layer, but I'm working on some direct GStreamer wrappers that already do the proper alignment. My plan currently is to keep working on gst-dsp until we have all the elements we need. After that's done we will be able to turn on the check in the kernel. Then, if I have time I might port the changes to TI's omx il. 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] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl
From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl Date: Tue, 9 Jun 2009 11:16:52 +0200 On Tue, Jun 9, 2009 at 10:02 AM, Hiroshi DOYUhiroshi.d...@nokia.com wrote: From: ext Kanigeri, Hari h-kanige...@ti.com Subject: RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl Date: Mon, 8 Jun 2009 22:49:21 +0200 Hi Doyu-san, Regarding http://marc.info/?l=linux-omapm=124201773423892w=2 I think that the first one should be merged into d.o-z.org now, but for the second one about 128 byte alignment. let me know your thought/plan on it. -- I think you sent this patch as a probable fix for the slab corruption that was observed in Bridge driver, but then we found that slab corruption was due to some other issue in Bridge driver and not due to the cache alignment. Irrespective of above point, I think it is good to enforce the cache alignment check, but I think the check should be in Proc Map function and to start with the check should be under a flag so as not to affect some MM applications that use padding to get over the alignment issue. I think that having configurable option may be reasonable practically, at the moment. But how about the longer term solution? Do you have any plan on how to deal with this? (ex: TI's OMX layer and some other userland client) Do you continue the userland buffer padding solution for the futer release? I don't know about TI's OMX layer, but I'm working on some direct GStreamer wrappers that already do the proper alignment. I expect that it will bring huge performance benfit. My plan currently is to keep working on gst-dsp until we have all the elements we need. After that's done we will be able to turn on the check in the kernel. Then, if I have time I might port the changes to TI's omx il. Both would be necessary for real products. 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 0/4]ARM: OMAP4: SMP: Patch series
Russell, -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, June 08, 2009 8:21 PM To: Shilimkar, Santosh Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: [PATCH 0/4]ARM: OMAP4: SMP: Patch series On Wed, May 27, 2009 at 09:52:38PM +0530, Shilimkar, Santosh wrote: I have rebased this series on top of your arm-smp patches and my earlier basic omap4 patches. Can you please rebase your patches on commit c7f7ff1 in my tree (it's in my devel branch) and I'll merge them in. (Please don't base patches on the top of the devel branch - you may notice it's a merge of 'devel-unstable' which is... unstable stuff.) I have rebased my patches on commit c7f7ff1 in your tree's devel branch. The 'arch/arm/mach-types' is still not updated in your tree so I added manually to test the functionality. Is it possible for you to pull these patches from following: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git for_rmk -shortlog Santosh Shilimkar(4) ARM: OMAP4: SMP: Update defconfig for OMAP4430 ARM: OMAP4: SMP: Enable SMP support for OMAP4430 ARM: OMAP4: SMP: Add mpu timer support for OMAP4430 ARM: OMAP4: SMP: Add OMAP4430 SMP board files -diffstat arch/arm/Kconfig |8 +- arch/arm/configs/omap_4430sdp_defconfig | 128 +- arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/omap-headsmp.S| 46 +++ arch/arm/mach-omap2/omap-smp.c| 178 + arch/arm/mach-omap2/timer-gp.c|4 + arch/arm/mach-omap2/timer-mpu.c | 34 + arch/arm/plat-omap/include/mach/entry-macro.S | 28 arch/arm/plat-omap/include/mach/irqs.h|2 + arch/arm/plat-omap/include/mach/smp.h | 51 +++ 10 files changed, 445 insertions(+), 38 deletions(-) create mode 100644 arch/arm/mach-omap2/omap-headsmp.S create mode 100644 arch/arm/mach-omap2/omap-smp.c create mode 100644 arch/arm/mach-omap2/timer-mpu.c create mode 100644 arch/arm/plat-omap/include/mach/smp.h Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] DSPBRIDGE: Various compile warning fixes
From: Mika Kukkonen mika.kukko...@nokia.com
This patch contains indentation fixes and cleans up various warnings
uncovered with extra warning flags:
- empty if() bodies
- incorrect use of unsigned variables
- bad comparison of pointer value
- pointless check of unsigned value being smaller than zero
- keyword 'extern' has to be first one in variable declaration
Signed-off-by: Mika Kukkonen mika.kukko...@nokia.com
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/dbc.h |6 +-
arch/arm/plat-omap/include/dspbridge/dbg.h |4 +-
arch/arm/plat-omap/include/dspbridge/gt.h | 16 ---
arch/arm/plat-omap/include/dspbridge/mem.h |2 +-
drivers/dsp/bridge/services/kfile.c|4 +-
drivers/dsp/bridge/wmd/io_sm.c | 72 ++--
drivers/dsp/bridge/wmd/ue_deh.c|2 +-
7 files changed, 54 insertions(+), 52 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dbc.h
b/arch/arm/plat-omap/include/dspbridge/dbc.h
index 0e6a67d..ec55c1d 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbc.h
@@ -57,9 +57,9 @@
#else
-#define DBC_Assert(exp)
-#define DBC_Require(exp)
-#define DBC_Ensure(exp)
+#define DBC_Assert(exp) {}
+#define DBC_Require(exp) {}
+#define DBC_Ensure(exp) {}
#endif /* DEBUG */
diff --git a/arch/arm/plat-omap/include/dspbridge/dbg.h
b/arch/arm/plat-omap/include/dspbridge/dbg.h
index 7f44ff9..442955c 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbg.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbg.h
@@ -101,9 +101,9 @@
extern DSP_STATUS DBG_Trace(IN u8 bLevel, IN char *pstrFormat, ...);
#else
-#define DBG_Exit(void)
+#define DBG_Exit(void) do {} while (0)
#define DBG_Init(void) true
-#define DBG_Trace(bLevel, pstrFormat, args...)
+#define DBG_Trace(bLevel, pstrFormat, args...) do {} while (0)
#endif /* (defined(DEBUG) || defined(DDSP_DEBUG_PRODUCT)) GT_TRACE */
diff --git a/arch/arm/plat-omap/include/dspbridge/gt.h
b/arch/arm/plat-omap/include/dspbridge/gt.h
index 456c866..72ef42d 100644
--- a/arch/arm/plat-omap/include/dspbridge/gt.h
+++ b/arch/arm/plat-omap/include/dspbridge/gt.h
@@ -261,13 +261,15 @@ extern struct GT_Config _GT_params;
#define GT_query(mask, class) false
-#define GT_0trace(mask, class, format)
-#define GT_1trace(mask, class, format, arg1)
-#define GT_2trace(mask, class, format, arg1, arg2)
-#define GT_3trace(mask, class, format, arg1, arg2, arg3)
-#define GT_4trace(mask, class, format, arg1, arg2, arg3, arg4)
-#define GT_5trace(mask, class, format, arg1, arg2, arg3, arg4, arg5)
-#define GT_6trace(mask, class, format, arg1, arg2, arg3, arg4, arg5, arg6)
+#define GT_0trace(mask, class, format) do {} while (0)
+#define GT_1trace(mask, class, format, arg1) do {} while (0)
+#define GT_2trace(mask, class, format, arg1, arg2) do {} while (0)
+#define GT_3trace(mask, class, format, arg1, arg2, arg3) do {} while (0)
+#define GT_4trace(mask, class, format, arg1, arg2, arg3, arg4) do {} while (0)
+#define GT_5trace(mask, class, format, arg1, arg2, arg3, arg4, arg5) \
+ do {} while (0)
+#define GT_6trace(mask, class, format, arg1, arg2, arg3, arg4, arg5, arg6) \
+ do {} while (0)
#else /* GT_TRACE == 1 */
diff --git a/arch/arm/plat-omap/include/dspbridge/mem.h
b/arch/arm/plat-omap/include/dspbridge/mem.h
index 535ac3a..cc79047 100644
--- a/arch/arm/plat-omap/include/dspbridge/mem.h
+++ b/arch/arm/plat-omap/include/dspbridge/mem.h
@@ -317,7 +317,7 @@
* Ensures:
* - pBaseAddr no longer points to a valid linear address.
*/
-#define MEM_UnmapLinearAddress(pBaseAddr)
+#define MEM_UnmapLinearAddress(pBaseAddr) {}
/*
* MEM_ExtPhysPoolInit
diff --git a/drivers/dsp/bridge/services/kfile.c
b/drivers/dsp/bridge/services/kfile.c
index ba1d26f..d29bc22 100644
--- a/drivers/dsp/bridge/services/kfile.c
+++ b/drivers/dsp/bridge/services/kfile.c
@@ -262,7 +262,7 @@ KFILE_Read(void __user*pBuffer, s32 cSize, s32 cCount,
s32 KFILE_Seek(struct KFILE_FileObj *hFile, s32 lOffset, s32 cOrigin)
{
s32 cRetVal = 0;/* 0 for success */
- u32 dwCurPos = 0;
+ loff_t dwCurPos = 0;
struct file *fileDesc = NULL;
@@ -315,7 +315,7 @@ s32 KFILE_Seek(struct KFILE_FileObj *hFile, s32 lOffset,
s32 cOrigin)
*/
s32 KFILE_Tell(struct KFILE_FileObj *hFile)
{
- u32 dwCurPos = 0;
+ loff_t dwCurPos = 0;
s32 lRetVal = E_KFILE_ERROR;
GT_1trace(KFILE_debugMask, GT_ENTER, KFILE_Tell: hFile 0x%x\n, hFile);
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 6f7e338..39c34f7 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -204,7 +204,7 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
struct CFG_HOSTRES hostRes;
struct CFG_DEVNODE *hDevNode;
Re: [PATCH] [MTD] [NAND] Add prefetch and dma support for omap2/3 NAND driver
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com [090608
09:01]:
On Mon, Jun 8, 2009 at 5:08 PM, Tony Lindgrent...@atomide.com wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com [090605
05:00]:
On Thu, Jun 4, 2009 at 8:58 PM, Tony Lindgrent...@atomide.com wrote:
* vimal singh vimalsi...@ti.com [090604 02:34]:
On Wed, Jun 3, 2009 at 10:03 PM, Tony Lindgren t...@atomide.com wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com
[090602
23:46]:
On Wed, Jun 3, 2009 at 2:06 AM, Tony Lindgren t...@atomide.com
wrote:
* vimal singh vimalsi...@ti.com [090602 05:40]:
This patch adds prefetch support to access nand flash in both mpu
and dma
mode.
This patch also adds 8-bit nand support (omap_read/write_buf8).
Prefetch can be used for both 8- and 16-bit devices.
This should be reviewed on the linux-omap@vger.kernel.org list for
sure.
One other comment below.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
I prepared this patch on top of OMAP2 / OMAP3 NAND driver patch:
http://lists.infradead.org/pipermail/linux-mtd/2009-May/025562.html
---
arch/arm/mach-omap2/gpmc.c | 102 ++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 17 +
drivers/mtd/nand/omap2.c | 308
-
4 files changed, 422 insertions(+), 9 deletions(-)
Index: mtd-2.6/arch/arm/mach-omap2/gpmc.c
===
--- mtd-2.6.orig/arch/arm/mach-omap2/gpmc.c
+++ mtd-2.6/arch/arm/mach-omap2/gpmc.c
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH 7
+#define DMA_MPU_MODE 2
+#endif
+
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -383,6 +389,99 @@ void gpmc_cs_free(int cs)
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/**
+ * gpmc_prefetch_init - configures default configuration for
prefetch
engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
Why would you want to have NAND specific init code int gpmc.c?
The purpose if gpmc.c is to provide access to configuring the
General Purpose Memory Controller (GPMC). You should just provide
functions in gpmc.c for the platform init code to use, and then
the drivers can stay platform independent.
In my understanding, this 'prefetch' engine is part of GPMC itself,
it is a
kind of feature provided by GPMC which can be utilized by NAND
driver.
So, to me, it makes sens to get initialized prefetch by GPMC itself
so that
NAND driver can use it.
But it should not have a dependency to NAND.
This engine, in GPMC, is dedicated for NAND devices only.
Another reason was that all read / write to GPMC register are done by
functions 'gpmc_read_reg' / 'gpmc_write_reg', which have been made
'static' in nature.
That's why you need to provide a generic function in gpmc.c to enable
prefetch that the platform code for any driver can use.
Exactly, and whenever a platform code uses gpmc init call, gpmc
initializes
this engine too. Since prefetch engine is the part of GPMC, IMHOP, it
should
get initialized as part of GPMC initialization.
No, the driver needing it should initialize it. There should not be any
ifdefs needed in the gpmc.c for that.
Are you suggesting to move gpmc prefetch specific code to
'drivers/mtd/nand/omap2.c'?
This can be done but then, we will be accessing gpmc registers outside
gpmc.c. Is that ok?
Well I'm thinking that you just basically need something like this in
gpmc.c:
int gpmc_prefetch_request(int cs);
int gpmc_prefetch_enable(int cs);
int gpmc_prefetch_reset(int cs);
...
And gpmc_prefetch_request would then return an error if already taken.
No need then to tinker with the GPMC prefetch registers in the NAND
driver.
This seems exactly what in this patch has been done, other than renaming the
functions and suggestion that gpmc prefetch init call should happen from NAND
driver and should return success or failure based on whether it
Re: [patch] Convert cbus driver code to use platform APIs consistently
* Andrew de Quincey adq_...@lidskialf.net [090608 12:56]: Recent changes in the drivers/base/platform.c exposed an inconsistency in the cbus drivers; they weren't matching platform_divers with platform_devices, which causes all sorts of structure casting issues within the base platform code since it assumes this. Signed-off-by: Andrew de Quincey a...@lidskialf.net The patch seems to be missing from the mail? 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-fbdev-devel] [PATCH 02/20] omapfb: Add support for MIPI-DCS compatible LCDs
Hi,
On Mon, Jun 08, 2009 at 12:43:24AM +0200, ext Krzysztof Helt wrote:
On Thu, 4 Jun 2009 20:52:27 +0300
Imre Deak imre.d...@nokia.com wrote:
[...]
+
+#define to_mipid_device(p) container_of(p, struct mipid_device, \
+ panel)
+struct mipid_device {
+ int enabled;
+ int model;
This one is only set and never read. A name is probably enough.
Ok, I'll remove model.
+ int revision;
+ u8 display_id[3];
This one should be a local variable.
Ok, I'll move it to the func where it's used.
+ unsigned intsaved_bklight_level;
+ unsigned long hw_guard_end; /* next value of jiffies
+ when we can issue the
+ next sleep in/out command */
+ unsigned long hw_guard_wait; /* max guard time in jiffies */
+
+ struct omapfb_device*fbdev;
+ struct spi_device *spi;
+ struct mutexmutex;
+ struct lcd_panelpanel;
How does it differ from fbdev-panel? Is it duplicated field?
fbdev-panel is a pointer to this device instance specific data. It's embedded
here
so that we can get to struct mipid_device with the container_of macro when
fbdev-panel
is passed to us.
I am sorry but I had not enough time to review the rest.
Thanks for the review, if there is nothing else I can post a new version with
the
above changes.
--Imre
--
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: Compiler wanrning fix for unlocked_ioctl
On Tue, Jun 9, 2009 at 12:29 PM, Hiroshi DOYUhiroshi.d...@nokia.com wrote: From: ext Felipe Contreras felipe.contre...@gmail.com Subject: Re: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl Date: Tue, 9 Jun 2009 11:16:52 +0200 On Tue, Jun 9, 2009 at 10:02 AM, Hiroshi DOYUhiroshi.d...@nokia.com wrote: From: ext Kanigeri, Hari h-kanige...@ti.com Subject: RE: [PATCH] DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl Date: Mon, 8 Jun 2009 22:49:21 +0200 Hi Doyu-san, Regarding http://marc.info/?l=linux-omapm=124201773423892w=2 I think that the first one should be merged into d.o-z.org now, but for the second one about 128 byte alignment. let me know your thought/plan on it. -- I think you sent this patch as a probable fix for the slab corruption that was observed in Bridge driver, but then we found that slab corruption was due to some other issue in Bridge driver and not due to the cache alignment. Irrespective of above point, I think it is good to enforce the cache alignment check, but I think the check should be in Proc Map function and to start with the check should be under a flag so as not to affect some MM applications that use padding to get over the alignment issue. I think that having configurable option may be reasonable practically, at the moment. But how about the longer term solution? Do you have any plan on how to deal with this? (ex: TI's OMX layer and some other userland client) Do you continue the userland buffer padding solution for the futer release? I don't know about TI's OMX layer, but I'm working on some direct GStreamer wrappers that already do the proper alignment. I expect that it will bring huge performance benfit. You mean because of the alignment or because of the implementation? In any case, you are correct :) My plan currently is to keep working on gst-dsp until we have all the elements we need. After that's done we will be able to turn on the check in the kernel. Then, if I have time I might port the changes to TI's omx il. Both would be necessary for real products. IMHO much more would be necessary for real products. Right now the DSP SW can read/write any location of memory (security risk?), I think all the memory should be protected and then the bridgedriver should give the DSP permissions on certain memory areas. -- 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
Source code for TI OMAP 3530 OpenGL h/w acceleration drivers
Hi, I'd like to obtain access to the source code for the TI OMAP 3530 PowerVR SGX graphics accelerator chip, so that I can recompile it against android's libc version and use it to accelerate the android-2.6.29 OpenGL implementation. Right now, without access to the sources, it won't be possible for anyone to utilize the OpenGL h/w capabilities of the TI OMAP 3530 processor, when used with android. I am using a Gumstix Overo Fire with android-2.6.29 kernel version. Elvis -- 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:WDT:Enable support for IVA and SECURE
Ulrik Bech Hald u...@ti.com writes:
This patch enables the IVA and SECURE WDTs in the omap_wdt
driver for omap34xx family. SECURE will be available as /dev/watchdog1
HS/EMU devices and IVA will be available as /dev/watchdog3.
MPU will be available as /dev/watchdog2
For omap versions earlier than 34xx only MPU watchdog is present and
will be available as /dev/watchdog for backwards compatibility.
Signed-off-by: Ulrik Bech Hald u...@ti.com
---
drivers/watchdog/omap_wdt.c | 42 +++---
1 files changed, 35 insertions(+), 7 deletions(-)
mode change 100644 = 100755 drivers/watchdog/omap_wdt.c
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
[...]
static int omap_wdt_open(struct inode *inode, struct file *file)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
- void __iomem *base = wdev-base;
+ struct omap_wdt_dev *wdev;
+ void __iomem *base;
+
+ /* by default MPU wdt is present across omap family */
+ wdev = platform_get_drvdata(omap_wdt_dev[1]);
+
+ /* if multiple wdts, find match between device node and wdt device */
+ if (cpu_is_omap34xx()) {
+ int i;
+ for (i = 0; i NUM_WDTS; i++) {
+ if (omap_wdt_dev[i]) {
+ wdev = platform_get_drvdata(omap_wdt_dev[i]);
+ if (iminor(inode)
+ == wdev-omap_wdt_miscdev.minor)
+ break;
+ }
+ }
+ }
+
+ base = wdev-base;
Hmm, this does not look right to me. Any use of cpu_is_* in driver
code usually indicates that something is not quite right. This same
watchdog IP is used in some DaVinci family processors and needs to be
reused there.
I didn't do the miscdev research, but can't you get the pdev from the
miscdev.parent, and from there get the right wdev pointer from the
pdev.drvdata.
Otherwise, drop the cpu_is_* and just do inode checking all the time.
The way you've done it looks error prone to me.
if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
return -EBUSY;
@@ -263,6 +283,7 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
struct resource *res, *mem;
struct omap_wdt_dev *wdev;
int ret;
+ static char wdt_name[32];
/* reserve static register mappings */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -271,7 +292,7 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
goto err_get_resource;
}
- if (omap_wdt_dev) {
+ if (omap_wdt_dev[pdev-id-1]) {
ret = -EBUSY;
goto err_busy;
}
@@ -318,8 +339,14 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
wdev-omap_wdt_miscdev.parent = pdev-dev;
wdev-omap_wdt_miscdev.minor = WATCHDOG_MINOR;
- wdev-omap_wdt_miscdev.name = watchdog;
wdev-omap_wdt_miscdev.fops = omap_wdt_fops;
+ wdev-omap_wdt_miscdev.name = watchdog;
+ if (cpu_is_omap34xx()) {
+ snprintf(wdt_name, sizeof(wdt_name), watchdog%d, pdev-id);
+ wdev-omap_wdt_miscdev.name = wdt_name;
+ if (pdev-id != 2)
+ wdev-omap_wdt_miscdev.minor = MISC_DYNAMIC_MINOR;
+ }
Again, red flag: cpu_is_*
It might be more consistent to use pdev-dev-name which is already of
the form watchdog.%d.
Any reason not to use MISC_DYNAMIC_MINOR for all of them?
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP3:WDT:Enable IVA, SECURE and minor bugfixes
Ulrik Bech Hald u...@ti.com writes: This patch series enables support for IVA and SECURE WDTs, available on omap34xx. For omap34xx devices the WDT will be accessible (when present) through: SECURE: /dev/watchdog1 MPU: /dev/watchdog2 IVA: /dev/watchdog3 For devices older than omap34xx only MPU WDT is present and will be accessible through /dev/watchdog I think you should make the MPU WDT the first one since it will always be present. The series also fixes two bugs: 1) Correct timeout value is not loaded upon opening the watchdog device. 2) clks are not enabled when accessing registers in probe Can you fix these existing bugs in a separate patch before you add the new features. 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: Please help in adding ams-delta support to ASoC
Jarkko Nikula wrote:
On Sat, 6 Jun 2009 00:28:00 +0200
Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote:
My last idea was to create a generic test driver that would not use
any external clocks, ie configured with OMAP_MCBSP_SYSCLK_CLK and
SND_SOC_DAIFMT_CBS_CFS, right? That way, it should just work without
any hardware support except for mcbsp and maybe we could then
definitelly verify if current mcbsp and dma code works on omap1510 or
not.
This could be a bit risky and can damage your HW since both OMAP and
codec are then driving the bit-clock and FS signals but you could try
to configure McBSP as a master and use the internal clock source as its
input.
I found that in OMAP5910, CLKR and FSR signals are not connected to any
pins, so I can safely set them as output. To make use of this feature, I
have modified sound/soc/omap/omap-mcbsp.c slightly:
diff -Npru linux-2.6.29/sound/soc/omap/omap-msbsp.c.orig
linux-2.6.29/sound/soc/omap/omap-mcbsp.c
--- linux-2.6.29/sound/soc/omap/omap-mcbsp.c.orig 2009-06-09
02:16:32.0 +0200
+++ linux-2.6.29/sound/soc/omap/omap-mcbsp.c2009-06-09
02:25:50.0 +0200
@@ -341,8 +341,8 @@ static int omap_mcbsp_dai_set_dai_fmt(st
switch (fmt SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:
/* McBSP master. Set FS and bit clocks as outputs */
- regs-pcr0 |= FSXM | FSRM |
- CLKXM | CLKRM;
+ regs-pcr0 |= FSRM |
+ CLKRM;
/* Sample rate generator drives the FS */
regs-srgr2 |= FSGM;
break;
Basically it goes with current driver by passing SND_SOC_DAIFMT_CBS_CFS
to snd_soc_dai_set_fmt(cpu_dai, ...) and by setting SRG source clock
and divider:
snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLK, ...);
snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, divider);
So I restored all that 12MHz mclk stuff that I had already removed as
redundant, then set up the following in oder to get internally generated
~256kHz CLKR and ~8kHz FSR:
+ /* Set cpu DAI configuration */
+ err = snd_soc_dai_set_fmt(cpu_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_IB_IF |
+ SND_SOC_DAIFMT_CBS_CFS);
+ if (err 0) {
+ printk(KERN_ERR can't set cpu DAI configuration\n);
+ return err;
+ }
+
+ /* Set cpu DAI master clock source */
+ err =
+ snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLK,
+ 0, SND_SOC_CLOCK_IN);
+
+ if (err 0) {
+ printk(KERN_ERR can't set cpu DAI clock source\n);
+ return err;
+ }
+
+ /* Set cpu DAI master clock divisor */
+ err =
+ snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, 47);
+
+ if (err 0) {
+ printk(KERN_ERR can't set cpu DAI clock divisor\n);
+ return err;
+ }
Tried with both arecord and /dev/dsp, it looks like the problem still
persists, even with mcbsp internally generated clocking. I have also
tested a similiar mcbsp configuration with old driver for reference - it
works.
Importand or not, I have to fine down my provious reports on what works
and what does not:
- original patch applied with other ams-delta related patches
on linux-omap-2.6.16, as it was designed for:
- playback: works, with both aplay and /dev/dsp,
- capture: works with /dev/dsp, gives null output with arecord
- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both /dev/dsp and arecord give null output,
but DMA interrupts still work.
- new driver on l-o: total hangup
- new driver on mainline 2.6.30-rc5: no DMA interrupts.
Thanks,
Janusz
--
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] Please help in adding ams-delta support to ASoC
Peter Ujfalusi wrote:
I'm kind of bad at visualizing things, is it possible to put somewhere the
screenshoot of the scope showing at least one sample?
Good idea. I'll take some screenshots for future reference and let you
know when available.
I have been looking for clues around the net, and it seams that the codec in
question has stereo 16 bit format.
From the very minimal mcbsp setup I get best audio experience with
(using original omap-alsa based driver - see below), it looks like the
codec speeks DSP (single phase), 16-bit mono @8kHz on output, but 8-bit
stereo @8kHz on input. Capturing one channel only (the first one) I
can't hear myself speaking, so audio from the microphone must be sent
over the second input channel.
+static struct omap_mcbsp_reg_cfg mcbsp_regs = {
+ .spcr2 = FREE | XINTM(3) | XRST,
+ .spcr1 = RINTM(3) | RRST,
+ .rcr1 = RFRLEN1(2 - 1) | RWDLEN1(OMAP_MCBSP_WORD_8),
+ .xcr1 = XFRLEN1(1 - 1) | XWDLEN1(OMAP_MCBSP_WORD_16),
+};
+static snd_pcm_hardware_t vc_snd_omap_alsa_playback = {
+ .info = (SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
+SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
+ .formats = (SNDRV_PCM_FMTBIT_S16_LE),
+ .rates = (SNDRV_PCM_RATE_8000 |
+ SNDRV_PCM_RATE_KNOT),
+ .rate_min = 8000,
+ .rate_max = 8000,
+ .channels_min = 1,
+ .channels_max = 1,
+ .buffer_bytes_max = 128 * 1024,
+ .period_bytes_min = 32,
+ .period_bytes_max = 8 * 1024,
+ .periods_min = 16,
+ .periods_max = 255,
+ .fifo_size = 0,
+};
+
+static snd_pcm_hardware_t vc_snd_omap_alsa_capture = {
+ .info = (SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
+SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
+ .formats = (SNDRV_PCM_FMTBIT_U8),
+ .rates = (SNDRV_PCM_RATE_8000 |
+ SNDRV_PCM_RATE_KNOT),
+ .rate_min = 8000,
+ .rate_max = 8000,
+ .channels_min = 2,
+ .channels_max = 2,
+ .buffer_bytes_max = 128 * 1024,
+ .period_bytes_min = 32,
+ .period_bytes_max = 8 * 1024,
+ .periods_min = 16,
+ .periods_max = 255,
+ .fifo_size = 0,
+};
For other combinations of single/dual phase, sample size, mono/stereo,
sound I get is much more distorted. Playing with polarisation and delays
for getting still better experience remains on my todo list.
BTW, I can't see any way of specifying a similiar mcbsp setup in new
omap asoc framework.
--
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -193,11 +193,15 @@ static int omap_pcm_trigger(struct snd_pcm_substream
*substream, int cmd)
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
prtd-period_index = 0;
omap_start_dma(prtd-dma_ch);
+ printk(omap_pcm_trigger START: DMA pointer at 0x%08x\n,
+ (unsigned)omap_get_dma_src_pos(prtd-dma_ch));
break;
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ printk(omap_pcm_trigger STOP: DMA pointer at 0x%08x\n,
+ (unsigned)omap_get_dma_src_pos(prtd-dma_ch));
prtd-period_index = -1;
omap_stop_dma(prtd-dma_ch);
break;
Than start a playback, and stop it with CTRL+C, see if the two pointers are
different...
Both playback and capture start with their own but always the same value
(something like 0x1101a0d0 for playback, 0xe101a0d0 for capture), and
always stop with this value unchanged.
2) I would I think try to port the 2.6.28 pure ALSA version to the head of l-
o, with minimal (only the needed) changes and see if it is still working.
Trying to use the new driver on the last l-o revision supporting both
omap-alsa and omap asoc, I got a broken system that hanged up completely
at sound device first access. The same for earlier and later l-o
revisions I have ever tried, unlike mainline that at least does not
hang. From all that I would conclude that porting the old driver could
be just waste of time, as the problem is probably omap asoc related, not
just omap, probably existed from the start of omap asoc life, and could
be solved on any l-o or mainline revision, including those eariler l-o
that supported both frameworks. But I can be wrong, of course.
Cheers,
Janusz
--
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] [MTD] [NAND] Add prefetch and dma support for omap2/3 NAND driver
On Tue, Jun 9, 2009 at 3:49 PM, Tony Lindgrent...@atomide.com wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com [090608
09:01]:
On Mon, Jun 8, 2009 at 5:08 PM, Tony Lindgrent...@atomide.com wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com [090605
05:00]:
On Thu, Jun 4, 2009 at 8:58 PM, Tony Lindgrent...@atomide.com wrote:
* vimal singh vimalsi...@ti.com [090604 02:34]:
On Wed, Jun 3, 2009 at 10:03 PM, Tony Lindgren t...@atomide.com
wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com
[090602
23:46]:
On Wed, Jun 3, 2009 at 2:06 AM, Tony Lindgren t...@atomide.com
wrote:
* vimal singh vimalsi...@ti.com [090602 05:40]:
This patch adds prefetch support to access nand flash in both
mpu and dma
mode.
This patch also adds 8-bit nand support (omap_read/write_buf8).
Prefetch can be used for both 8- and 16-bit devices.
This should be reviewed on the linux-omap@vger.kernel.org list
for sure.
One other comment below.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
I prepared this patch on top of OMAP2 / OMAP3 NAND driver
patch:
http://lists.infradead.org/pipermail/linux-mtd/2009-May/025562.html
---
arch/arm/mach-omap2/gpmc.c | 102 ++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 17 +
drivers/mtd/nand/omap2.c | 308
-
4 files changed, 422 insertions(+), 9 deletions(-)
Index: mtd-2.6/arch/arm/mach-omap2/gpmc.c
===
--- mtd-2.6.orig/arch/arm/mach-omap2/gpmc.c
+++ mtd-2.6/arch/arm/mach-omap2/gpmc.c
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH 7
+#define DMA_MPU_MODE 2
+#endif
+
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -383,6 +389,99 @@ void gpmc_cs_free(int cs)
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/**
+ * gpmc_prefetch_init - configures default configuration for
prefetch
engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
Why would you want to have NAND specific init code int gpmc.c?
The purpose if gpmc.c is to provide access to configuring the
General Purpose Memory Controller (GPMC). You should just provide
functions in gpmc.c for the platform init code to use, and then
the drivers can stay platform independent.
In my understanding, this 'prefetch' engine is part of GPMC itself,
it is a
kind of feature provided by GPMC which can be utilized by NAND
driver.
So, to me, it makes sens to get initialized prefetch by GPMC itself
so that
NAND driver can use it.
But it should not have a dependency to NAND.
This engine, in GPMC, is dedicated for NAND devices only.
Another reason was that all read / write to GPMC register are done
by
functions 'gpmc_read_reg' / 'gpmc_write_reg', which have been made
'static' in nature.
That's why you need to provide a generic function in gpmc.c to enable
prefetch that the platform code for any driver can use.
Exactly, and whenever a platform code uses gpmc init call, gpmc
initializes
this engine too. Since prefetch engine is the part of GPMC, IMHOP, it
should
get initialized as part of GPMC initialization.
No, the driver needing it should initialize it. There should not be any
ifdefs needed in the gpmc.c for that.
Are you suggesting to move gpmc prefetch specific code to
'drivers/mtd/nand/omap2.c'?
This can be done but then, we will be accessing gpmc registers outside
gpmc.c. Is that ok?
Well I'm thinking that you just basically need something like this in
gpmc.c:
int gpmc_prefetch_request(int cs);
int gpmc_prefetch_enable(int cs);
int gpmc_prefetch_reset(int cs);
...
And gpmc_prefetch_request would then return an error if already taken.
No need then to tinker with the GPMC prefetch registers in the NAND
driver.
This seems exactly what in this patch has been done, other than renaming the
functions and suggestion that gpmc prefetch init call
Re: [PATCH] [MTD] [NAND] Add prefetch and dma support for omap2/3 NAND driver
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com [090609
08:24]:
On Tue, Jun 9, 2009 at 3:49 PM, Tony Lindgrent...@atomide.com wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com [090608
09:01]:
On Mon, Jun 8, 2009 at 5:08 PM, Tony Lindgrent...@atomide.com wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com
[090605 05:00]:
On Thu, Jun 4, 2009 at 8:58 PM, Tony Lindgrent...@atomide.com wrote:
* vimal singh vimalsi...@ti.com [090604 02:34]:
On Wed, Jun 3, 2009 at 10:03 PM, Tony Lindgren t...@atomide.com
wrote:
* Singh, Vimal
imceaex-_o=ti_ou=bd_cn=recipients_cn=x0094...@dlee86.itg.ti.com
[090602
23:46]:
On Wed, Jun 3, 2009 at 2:06 AM, Tony Lindgren t...@atomide.com
wrote:
* vimal singh vimalsi...@ti.com [090602 05:40]:
This patch adds prefetch support to access nand flash in both
mpu and dma
mode.
This patch also adds 8-bit nand support (omap_read/write_buf8).
Prefetch can be used for both 8- and 16-bit devices.
This should be reviewed on the linux-omap@vger.kernel.org list
for sure.
One other comment below.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
I prepared this patch on top of OMAP2 / OMAP3 NAND driver
patch:
http://lists.infradead.org/pipermail/linux-mtd/2009-May/025562.html
---
arch/arm/mach-omap2/gpmc.c | 102 ++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 17 +
drivers/mtd/nand/omap2.c | 308
-
4 files changed, 422 insertions(+), 9 deletions(-)
Index: mtd-2.6/arch/arm/mach-omap2/gpmc.c
===
--- mtd-2.6.orig/arch/arm/mach-omap2/gpmc.c
+++ mtd-2.6/arch/arm/mach-omap2/gpmc.c
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH 7
+#define DMA_MPU_MODE 2
+#endif
+
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -383,6 +389,99 @@ void gpmc_cs_free(int cs)
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/**
+ * gpmc_prefetch_init - configures default configuration for
prefetch
engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
Why would you want to have NAND specific init code int gpmc.c?
The purpose if gpmc.c is to provide access to configuring the
General Purpose Memory Controller (GPMC). You should just
provide
functions in gpmc.c for the platform init code to use, and then
the drivers can stay platform independent.
In my understanding, this 'prefetch' engine is part of GPMC
itself, it is a
kind of feature provided by GPMC which can be utilized by NAND
driver.
So, to me, it makes sens to get initialized prefetch by GPMC
itself so that
NAND driver can use it.
But it should not have a dependency to NAND.
This engine, in GPMC, is dedicated for NAND devices only.
Another reason was that all read / write to GPMC register are
done by
functions 'gpmc_read_reg' / 'gpmc_write_reg', which have been made
'static' in nature.
That's why you need to provide a generic function in gpmc.c to
enable
prefetch that the platform code for any driver can use.
Exactly, and whenever a platform code uses gpmc init call, gpmc
initializes
this engine too. Since prefetch engine is the part of GPMC, IMHOP,
it should
get initialized as part of GPMC initialization.
No, the driver needing it should initialize it. There should not be
any
ifdefs needed in the gpmc.c for that.
Are you suggesting to move gpmc prefetch specific code to
'drivers/mtd/nand/omap2.c'?
This can be done but then, we will be accessing gpmc registers outside
gpmc.c. Is that ok?
Well I'm thinking that you just basically need something like this in
gpmc.c:
int gpmc_prefetch_request(int cs);
int gpmc_prefetch_enable(int cs);
int gpmc_prefetch_reset(int cs);
...
And gpmc_prefetch_request would then
[PATCH] OMAP3: PM: Program SDRC to send self refresh on timeout of AUTO_CNT
Due to an OMAP3 errata (1.142), on HS/EMU devices SDRC should be
programed to issue automatic self refresh on timeout
of AUTO_CNT = 1 prior to any transition to OFF mode.
This is needed only on sil rev's ES3.0 and above.
This patch enables the above needed WA in the SDRC power register
value stored in scratchpad, so that ROM code restores this value
in SDRC POWER on the wakeup path.
The original SDRC POWER register value is stored and restored back
in omap_sram_idle() function.
This fixes some random crashes observed while stressing suspend
on HS/EMU devices.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
---
arch/arm/mach-omap2/control.c | 16 +++-
arch/arm/mach-omap2/pm34xx.c | 24 +++-
arch/arm/plat-omap/include/mach/sdrc.h |6 ++
3 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 60de860..c9407c0 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -265,7 +265,21 @@ void omap3_save_scratchpad_contents(void)
(sdrc_read_reg(SDRC_ERR_TYPE) 0x);
sdrc_block_contents.dll_a_ctrl = sdrc_read_reg(SDRC_DLLA_CTRL);
sdrc_block_contents.dll_b_ctrl = 0x0;
- sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
+ /*
+* Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should
+* be programed to issue automatic self refresh on timeout
+* of AUTO_CNT = 1 prior to any transition to OFF mode.
+*/
+ if ((omap_type() != OMAP2_DEVICE_TYPE_GP)
+(omap_rev() = OMAP3430_REV_ES3_0))
+ sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER)
+ ~(SDRC_POWER_AUTOCOUNT_MASK|
+ SDRC_POWER_CLKCTRL_MASK)) |
+ (1 SDRC_POWER_AUTOCOUNT_SHIFT) |
+ SDRC_SELF_REFRESH_ON_AUTOCOUNT;
+ else
+ sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER);
+
sdrc_block_contents.cs_0 = 0x0;
sdrc_block_contents.mcfg_0 = sdrc_read_reg(SDRC_MCFG_0);
sdrc_block_contents.mr_0 = (sdrc_read_reg(SDRC_MR_0) 0x);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b925501..a9ef670 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -57,12 +57,6 @@
static int regset_save_on_suspend;
-#define SDRC_POWER_AUTOCOUNT_SHIFT 8
-#define SDRC_POWER_AUTOCOUNT_MASK (0x SDRC_POWER_AUTOCOUNT_SHIFT)
-#define SDRC_POWER_CLKCTRL_SHIFT 4
-#define SDRC_POWER_CLKCTRL_MASK (0x3 SDRC_POWER_CLKCTRL_SHIFT)
-#define SDRC_SELF_REFRESH_ON_AUTOCOUNT (0x2 SDRC_POWER_CLKCTRL_SHIFT)
-
/* Scratchpad offsets */
#define OMAP343X_TABLE_ADDRESS_OFFSET 0x31
#define OMAP343X_TABLE_VALUE_OFFSET 0x30
@@ -405,19 +399,15 @@ void omap_sram_idle(void)
}
/*
-* Force SDRAM controller to self-refresh mode after timeout on
-* autocount. This is needed on ES3.0 to avoid SDRAM controller
-* hang-ups.
-*/
+ * On EMU/HS devices ROM code restores a SRDC value
+ * from scratchpad which has automatic self refresh on timeout
+ * of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
+ * Hence store/restore the SDRC_POWER register here.
+ */
if (omap_rev() = OMAP3430_REV_ES3_0
omap_type() != OMAP2_DEVICE_TYPE_GP
- core_next_state == PWRDM_POWER_OFF) {
+ core_next_state == PWRDM_POWER_OFF)
sdrc_pwr = sdrc_read_reg(SDRC_POWER);
- sdrc_write_reg((sdrc_pwr
- ~(SDRC_POWER_AUTOCOUNT_MASK|SDRC_POWER_CLKCTRL_MASK)) |
- (1 SDRC_POWER_AUTOCOUNT_SHIFT) |
- SDRC_SELF_REFRESH_ON_AUTOCOUNT, SDRC_POWER);
- }
if (regset_save_on_suspend)
pm_dbg_regset_save(1);
@@ -430,7 +420,7 @@ void omap_sram_idle(void)
_omap_sram_idle(omap3_arm_context, save_state);
cpu_init();
- /* Restore normal SDRAM settings */
+ /* Restore normal SDRC POWER settings */
if (omap_rev() = OMAP3430_REV_ES3_0
omap_type() != OMAP2_DEVICE_TYPE_GP
core_next_state == PWRDM_POWER_OFF)
diff --git a/arch/arm/plat-omap/include/mach/sdrc.h
b/arch/arm/plat-omap/include/mach/sdrc.h
index a678bc8..4af5c6a 100644
--- a/arch/arm/plat-omap/include/mach/sdrc.h
+++ b/arch/arm/plat-omap/include/mach/sdrc.h
@@ -44,6 +44,12 @@
#define SDRC_RFR_CTRL_10x0D4
#define SDRC_MANUAL_1 0x0D8
+#define SDRC_POWER_AUTOCOUNT_SHIFT 8
+#define SDRC_POWER_AUTOCOUNT_MASK (0x SDRC_POWER_AUTOCOUNT_SHIFT)
+#define SDRC_POWER_CLKCTRL_SHIFT 4
+#define SDRC_POWER_CLKCTRL_MASK(0x3
SDRC_POWER_CLKCTRL_SHIFT)
+#define
Re: [patch] Convert cbus driver code to use platform APIs consistently
Quoting Tony Lindgren t...@atomide.com:
* Andrew de Quincey adq_...@lidskialf.net [090608 12:56]:
Recent changes in the drivers/base/platform.c exposed an inconsistency
in the cbus drivers; they weren't matching platform_divers with
platform_devices, which causes all sorts of structure casting issues
within the base platform code since it assumes this.
Signed-off-by: Andrew de Quincey a...@lidskialf.net
The patch seems to be missing from the mail?
gah, FAIL.
Attached :)
commit 20c2956fc541bb327f4a2df41dbe5ff50261749f
Author: Andrew de Quincey a...@lidskialf.net
Date: Mon May 25 22:56:01 2009 +0100
Fix cbus to use platform APIs
diff --git a/drivers/cbus/retu-rtc.c b/drivers/cbus/retu-rtc.c
index 1ebc33b..76343f9 100644
--- a/drivers/cbus/retu-rtc.c
+++ b/drivers/cbus/retu-rtc.c
@@ -361,7 +361,7 @@ static int retu_rtc_init_irq(void)
}
-static int __devinit retu_rtc_probe(struct device *dev)
+static int __devinit retu_rtc_probe(struct platform_device *pdev)
{
int r;
@@ -380,48 +380,49 @@ static int __devinit retu_rtc_probe(struct device *dev)
else
retu_rtc_do_reset();
- if ((r = device_create_file(dev, dev_attr_time)) != 0)
+ if ((r = device_create_file((pdev-dev), dev_attr_time)) != 0)
return r;
- else if ((r = device_create_file(dev, dev_attr_reset)) != 0)
+ else if ((r = device_create_file((pdev-dev), dev_attr_reset)) != 0)
goto err_unregister_time;
- else if ((r = device_create_file(dev, dev_attr_alarm)) != 0)
+ else if ((r = device_create_file((pdev-dev), dev_attr_alarm)) != 0)
goto err_unregister_reset;
- else if ((r = device_create_file(dev, dev_attr_alarm_expired)) != 0)
+ else if ((r = device_create_file((pdev-dev), dev_attr_alarm_expired)) != 0)
goto err_unregister_alarm;
- else if ((r = device_create_file(dev, dev_attr_cal)) != 0)
+ else if ((r = device_create_file((pdev-dev), dev_attr_cal)) != 0)
goto err_unregister_alarm_expired;
else
return r;
err_unregister_alarm_expired:
- device_remove_file(dev, dev_attr_alarm_expired);
+ device_remove_file((pdev-dev), dev_attr_alarm_expired);
err_unregister_alarm:
- device_remove_file(dev, dev_attr_alarm);
+ device_remove_file((pdev-dev), dev_attr_alarm);
err_unregister_reset:
- device_remove_file(dev, dev_attr_reset);
+ device_remove_file((pdev-dev), dev_attr_reset);
err_unregister_time:
- device_remove_file(dev, dev_attr_time);
+ device_remove_file((pdev-dev), dev_attr_time);
return r;
}
-static int __devexit retu_rtc_remove(struct device *dev)
+static int __devexit retu_rtc_remove(struct platform_device *pdev)
{
retu_disable_irq(RETU_INT_RTCS);
retu_free_irq(RETU_INT_RTCS);
retu_free_irq(RETU_INT_RTCA);
- device_remove_file(dev, dev_attr_cal);
- device_remove_file(dev, dev_attr_alarm_expired);
- device_remove_file(dev, dev_attr_alarm);
- device_remove_file(dev, dev_attr_reset);
- device_remove_file(dev, dev_attr_time);
+ device_remove_file((pdev-dev), dev_attr_cal);
+ device_remove_file((pdev-dev), dev_attr_alarm_expired);
+ device_remove_file((pdev-dev), dev_attr_alarm);
+ device_remove_file((pdev-dev), dev_attr_reset);
+ device_remove_file((pdev-dev), dev_attr_time);
return 0;
}
-static struct device_driver retu_rtc_driver = {
- .name = retu-rtc,
- .bus = platform_bus_type,
+static struct platform_driver retu_rtc_driver = {
.probe = retu_rtc_probe,
.remove = __devexit_p(retu_rtc_remove),
+ .driver = {
+ .name = retu-rtc,
+ }
};
static struct platform_device retu_rtc_device = {
@@ -448,7 +449,7 @@ static int __init retu_rtc_init(void)
init_completion(retu_rtc_exited);
- if ((ret = driver_register(retu_rtc_driver)) != 0)
+ if ((ret = platform_driver_register(retu_rtc_driver)) != 0)
return ret;
if ((ret = platform_device_register(retu_rtc_device)) != 0)
@@ -457,14 +458,14 @@ static int __init retu_rtc_init(void)
return 0;
err_unregister_driver:
- driver_unregister(retu_rtc_driver);
+ platform_driver_unregister(retu_rtc_driver);
return ret;
}
static void __exit retu_rtc_exit(void)
{
platform_device_unregister(retu_rtc_device);
- driver_unregister(retu_rtc_driver);
+ platform_driver_unregister(retu_rtc_driver);
wait_for_completion(retu_rtc_exited);
}
diff --git a/drivers/cbus/retu-wdt.c b/drivers/cbus/retu-wdt.c
index b7b20b7..1fa181e 100644
--- a/drivers/cbus/retu-wdt.c
+++ b/drivers/cbus/retu-wdt.c
@@ -104,20 +104,20 @@ static DEVICE_ATTR(period, S_IRUGO | S_IWUSR, retu_wdt_period_show, \
retu_wdt_period_store);
static DEVICE_ATTR(counter, S_IRUGO, retu_wdt_counter_show, NULL);
-static int __devinit retu_wdt_probe(struct device *dev)
+static int __devinit retu_wdt_probe(struct platform_device *pdev)
{
int ret;
- ret = device_create_file(dev, dev_attr_period);
+ ret = device_create_file((pdev-dev), dev_attr_period);
if (ret) {
printk(KERN_ERR retu_wdt_probe: Error creating
sys device file: period\n);
return ret;
}
- ret = device_create_file(dev, dev_attr_counter);
+ ret = device_create_file((pdev-dev),
MUSB Host problems
I'm trying to get MUSB Host working on my 3530 platform (very similar to the Beagle). When I startup, I get this message: Clock usbhost_48m_fck didn't enable in 10 tries What does this mean? How do I fix it? Currently, the USB subsystem finds the various hubs (ports 0-2). The OTG port (0) works great. When I plug in a device to USB-1, it sees it, but immediately gives up :-( ehci-omap ehci-omap.0: GetStatus port 1 status 001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 1: status 0501 change 0001 hub 1-0:1.0: state 7 ports 3 chg 0002 evt hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s ehci-omap ehci-omap.0: port 1 full speed -- companion ehci-omap ehci-omap.0: GetStatus port 1 status 003801 POWER OWNER sig=j CONNECT hub 1-0:1.0: port 1 not reset yet, waiting 50ms ehci-omap ehci-omap.0: GetStatus port 1 status 003002 POWER OWNER sig=se0 CSC hub 1-0:1.0: unable to enumerate USB device on port 1 hub 1-0:1.0: state 7 ports 3 chg evt 0002 hub 1-0:1.0: hub_suspend Then it's dead. Any ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: MUSB Host problems
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Tuesday, June 09, 2009 12:46 PM To: linux-omap@vger.kernel.org Subject: MUSB Host problems I'm trying to get MUSB Host working on my 3530 platform (very Based on your description, its not MUSB but the USBHOST EHCI block that you want to get working. similar to the Beagle). When I startup, I get this message: Clock usbhost_48m_fck didn't enable in 10 tries This is bad What does this mean? How do I fix it? Currently, the USB subsystem finds the various hubs (ports 0-2). The OTG port (0) works great. When I plug in a device to USB-1, Is this a full speed device? it sees it, but immediately gives up :-( ehci-omap ehci-omap.0: GetStatus port 1 status 001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 1: status 0501 change 0001 hub 1-0:1.0: state 7 ports 3 chg 0002 evt hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s ehci-omap ehci-omap.0: port 1 full speed -- companion Looks like your device is getting recognized as a full speed. So EHCI cannot handle it. You need to have OHCI driver built in which is not present in linux-omap code base. ehci-omap ehci-omap.0: GetStatus port 1 status 003801 POWER OWNER sig=j CONNECT hub 1-0:1.0: port 1 not reset yet, waiting 50ms ehci-omap ehci-omap.0: GetStatus port 1 status 003002 POWER OWNER sig=se0 CSC hub 1-0:1.0: unable to enumerate USB device on port 1 hub 1-0:1.0: state 7 ports 3 chg evt 0002 hub 1-0:1.0: hub_suspend Then it's dead. Any ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 0/3] OMAP3:WDT:Enable IVA, SECURE and minor bugfixes
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, June 09, 2009 9:45 AM To: Hald, Ulrik Bech Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 0/3] OMAP3:WDT:Enable IVA, SECURE and minor bugfixes Ulrik Bech Hald u...@ti.com writes: This patch series enables support for IVA and SECURE WDTs, available on omap34xx. For omap34xx devices the WDT will be accessible (when present) through: SECURE:/dev/watchdog1 MPU: /dev/watchdog2 IVA: /dev/watchdog3 For devices older than omap34xx only MPU WDT is present and will be accessible through /dev/watchdog I think you should make the MPU WDT the first one since it will always be present. The reason, why I numbered them as above, is to make them match the OMAP34xx TRM WDT numbering scheme, where SECURE WDT=WDT1, MPU WDT=WDT2 and IVA WDT=WDT3. My thought was that it would introduce more confusion to change the numbers in /dev/ to something else, although I did consider your point. Do you still think I should change the numbers? The series also fixes two bugs: 1) Correct timeout value is not loaded upon opening the watchdog device. 2) clks are not enabled when accessing registers in probe Can you fix these existing bugs in a separate patch before you add the new features. Sure, no problem. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP3:WDT:Enable IVA, SECURE and minor bugfixes
Hald, Ulrik Bech u...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, June 09, 2009 9:45 AM To: Hald, Ulrik Bech Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 0/3] OMAP3:WDT:Enable IVA, SECURE and minor bugfixes Ulrik Bech Hald u...@ti.com writes: This patch series enables support for IVA and SECURE WDTs, available on omap34xx. For omap34xx devices the WDT will be accessible (when present) through: SECURE: /dev/watchdog1 MPU: /dev/watchdog2 IVA: /dev/watchdog3 For devices older than omap34xx only MPU WDT is present and will be accessible through /dev/watchdog I think you should make the MPU WDT the first one since it will always be present. The reason, why I numbered them as above, is to make them match the OMAP34xx TRM WDT numbering scheme, where SECURE WDT=WDT1, MPU WDT=WDT2 and IVA WDT=WDT3. My thought was that it would introduce more confusion to change the numbers in /dev/ to something else, although I did consider your point. Do you still think I should change the numbers? Yes. Personally, I don't think the TRM should influence userspace visible nodes in this case. I would rather see the watchdog that exists on all platforms be the first one. 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: MUSB Host problems
Pandita, Vikram wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Tuesday, June 09, 2009 12:46 PM To: linux-omap@vger.kernel.org Subject: MUSB Host problems I'm trying to get MUSB Host working on my 3530 platform (very Based on your description, its not MUSB but the USBHOST EHCI block that you want to get working. Sorry, mistaken terminology. Yes, I'm trying to get the host ECHI working. similar to the Beagle). When I startup, I get this message: Clock usbhost_48m_fck didn't enable in 10 tries This is bad Why? What does it mean? How do I fix it? What does this mean? How do I fix it? Currently, the USB subsystem finds the various hubs (ports 0-2). The OTG port (0) works great. When I plug in a device to USB-1, Is this a full speed device? it sees it, but immediately gives up :-( ehci-omap ehci-omap.0: GetStatus port 1 status 001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 1: status 0501 change 0001 hub 1-0:1.0: state 7 ports 3 chg 0002 evt hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s ehci-omap ehci-omap.0: port 1 full speed -- companion Looks like your device is getting recognized as a full speed. So EHCI cannot handle it. Odd, this is a high speed device (USB 2.0). I also tried a 2.0 hub, same result. What could confuse it like this? You need to have OHCI driver built in which is not present in linux-omap code base. Do, how does one use an arbitrary device on the EHCI port? Must I use a 2.0 hub? ehci-omap ehci-omap.0: GetStatus port 1 status 003801 POWER OWNER sig=j CONNECT hub 1-0:1.0: port 1 not reset yet, waiting 50ms ehci-omap ehci-omap.0: GetStatus port 1 status 003002 POWER OWNER sig=se0 CSC hub 1-0:1.0: unable to enumerate USB device on port 1 hub 1-0:1.0: state 7 ports 3 chg evt 0002 hub 1-0:1.0: hub_suspend Then it's dead. Any ideas? Note: this is unproven hardware, I'm mostly looking for ideas on how to troubleshoot the problems. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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:WDT:Enable support for IVA and SECURE
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, June 09, 2009 9:47 AM
To: Hald, Ulrik Bech
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/3] OMAP3:WDT:Enable support for IVA and SECURE
Ulrik Bech Hald u...@ti.com writes:
This patch enables the IVA and SECURE WDTs in the omap_wdt
driver for omap34xx family. SECURE will be available as /dev/watchdog1
HS/EMU devices and IVA will be available as /dev/watchdog3.
MPU will be available as /dev/watchdog2
For omap versions earlier than 34xx only MPU watchdog is present and
will be available as /dev/watchdog for backwards compatibility.
Signed-off-by: Ulrik Bech Hald u...@ti.com
---
drivers/watchdog/omap_wdt.c | 42 +++-
--
1 files changed, 35 insertions(+), 7 deletions(-)
mode change 100644 = 100755 drivers/watchdog/omap_wdt.c
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
[...]
static int omap_wdt_open(struct inode *inode, struct file *file)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
- void __iomem *base = wdev-base;
+ struct omap_wdt_dev *wdev;
+ void __iomem *base;
+
+ /* by default MPU wdt is present across omap family */
+ wdev = platform_get_drvdata(omap_wdt_dev[1]);
+
+ /* if multiple wdts, find match between device node and wdt device
*/
+ if (cpu_is_omap34xx()) {
+ int i;
+ for (i = 0; i NUM_WDTS; i++) {
+ if (omap_wdt_dev[i]) {
+ wdev = platform_get_drvdata(omap_wdt_dev[i]);
+ if (iminor(inode)
+ == wdev-omap_wdt_miscdev.minor)
+ break;
+ }
+ }
+ }
+
+ base = wdev-base;
Hmm, this does not look right to me. Any use of cpu_is_* in driver
code usually indicates that something is not quite right. This same
watchdog IP is used in some DaVinci family processors and needs to be
reused there.
I didn't do the miscdev research, but can't you get the pdev from the
miscdev.parent, and from there get the right wdev pointer from the
pdev.drvdata.
Otherwise, drop the cpu_is_* and just do inode checking all the time.
The way you've done it looks error prone to me.
I can't really see a to way pair the driver and device other than doing
inode/minor number checking , so I'll just go for the inode checking without
any dependency on cpu_is_xxx().
if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
return -EBUSY;
@@ -263,6 +283,7 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
struct resource *res, *mem;
struct omap_wdt_dev *wdev;
int ret;
+ static char wdt_name[32];
/* reserve static register mappings */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -271,7 +292,7 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
goto err_get_resource;
}
- if (omap_wdt_dev) {
+ if (omap_wdt_dev[pdev-id-1]) {
ret = -EBUSY;
goto err_busy;
}
@@ -318,8 +339,14 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
wdev-omap_wdt_miscdev.parent = pdev-dev;
wdev-omap_wdt_miscdev.minor = WATCHDOG_MINOR;
- wdev-omap_wdt_miscdev.name = watchdog;
wdev-omap_wdt_miscdev.fops = omap_wdt_fops;
+ wdev-omap_wdt_miscdev.name = watchdog;
+ if (cpu_is_omap34xx()) {
+ snprintf(wdt_name, sizeof(wdt_name), watchdog%d, pdev-id);
+ wdev-omap_wdt_miscdev.name = wdt_name;
+ if (pdev-id != 2)
+ wdev-omap_wdt_miscdev.minor = MISC_DYNAMIC_MINOR;
+ }
Again, red flag: cpu_is_*
It might be more consistent to use pdev-dev-name which is already of
the form watchdog.%d.
Not sure I follow. I don't see a name field in struct device, only init_name.
Do you mean just using:
snprintf(wdt_name, sizeof(wdt_name), watchdog%d, pdev-id);
wdev-omap_wdt_miscdev.name = wdt_name;
...for all the WDT devices, despite how many are present?
Any reason not to use MISC_DYNAMIC_MINOR for all of them?
No particular reason other than I thought that retaining the use of
WATCHDOG_MINOR for the MPU WDT case would be appropriate. But it does make the
code cleaner to use only MISC_DYNAMIC_MINOR. I'll change it.
Thanks for reviewing!
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
omap-pm: Console not suspending
Hi,
I'm using the latest pm patches with android-2.6.29, and I have a new
situation where the console tries to suspend, it tries to fade a bit,
but then wakes up. On the console output, I see the following error
message:
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
pwrdm when mpu_pwrdm wakes up
wakeup wake lock: mmc_delayed_work
Spurious irq 95: 0xffdf, please flush posted write for irq 86
Spurious irq 95: 0xffdf, please flush posted write for irq 86
mmc1: mmc_rescan - card ocr from io_op=0x, err = -110
PM: resume devices took 0.554 seconds
Restarting tasks ... 7hub 1-0:1.0: state 7 ports 1 chg evt
done.
suspend: exit suspend, ret = 0 (2000-01-01 00:05:56.543487549 UTC)
PM: Syncing filesystems ... done.
Should these options be set?
# CONFIG_NO_USER_SPACE_SCREEN_ACCESS_CONTROL is not set
# CONFIG_CONSOLE_EARLYSUSPEND is not set
I have recently made some u-boot modifications to enable UART2. One of
the changes removed GPIO_144 - LCD EN as shown below.
Will that have any effect?
iff --git a/board/omap3/overo/overo.h b/board/omap3/overo/overo.h
index b595f6a..5597910 100644
--- a/board/omap3/overo/overo.h
+++ b/board/omap3/overo/overo.h
@@ -213,14 +213,14 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(MMC2_DAT6),(IEN | PTU | EN | M1))
/*MMC2_DIR_CMD*/\
MUX_VAL(CP(MMC2_DAT7),(IEN | PTU | EN | M1)) /*MMC2_CLKIN*/\
/*Bluetooth*/\
- MUX_VAL(CP(MCBSP3_DX),(IEN | PTD | DIS | M1)) /*UART2_CTS*/\
- MUX_VAL(CP(MCBSP3_DR),(IDIS | PTD | DIS | M1)) /*UART2_RTS*/\
- MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M1)) /*UART2_TX*/\
- MUX_VAL(CP(MCBSP3_FSX), (IEN | PTD | DIS | M1)) /*UART2_RX*/\
- MUX_VAL(CP(UART2_CTS), (IEN | PTD | DIS | M4)) /*GPIO_144 -
LCD_EN*/\
- MUX_VAL(CP(UART2_RTS),(IEN | PTD | DIS | M4)) /*GPIO_145*/\
- MUX_VAL(CP(UART2_TX), (IEN | PTD | DIS | M4)) /*GPIO_146*/\
- MUX_VAL(CP(UART2_RX), (IEN | PTD | DIS | M4)) /*GPIO_147*/\
+ MUX_VAL(CP(MCBSP3_DX), (IDIS | PTD | DIS | M0)) /*McBSP3_DX*/\
+ MUX_VAL(CP(MCBSP3_DR), (IEN | PTD | DIS | M0)) /*McBSP3_DR*/\
+ MUX_VAL(CP(MCBSP3_CLKX), (IEN | PTD | DIS | M0)) /
*McBSP3_CLKX*/\
+ MUX_VAL(CP(MCBSP3_FSX),(IEN | PTD | DIS | M0)) /
*McBSP3_FSX*/\
+ MUX_VAL(CP(UART2_CTS), (IEN | PTU | EN | M0)) /*UART2_CTS*/\
+ MUX_VAL(CP(UART2_RTS), (IDIS | PTD | DIS | M0)) /*UART2_RTS*/\
+ MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M0)) /*UART2_TX*/\
+ MUX_VAL(CP(UART2_RX), (IEN | PTD | DIS | M0)) /*UART2_RX*/\
MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /*UART1_TX*/\
MUX_VAL(CP(UART1_RTS),(IEN | PTU | DIS | M4)) /*GPIO_149*/ \
MUX_VAL(CP(UART1_CTS), (IEN | PTU | DIS | M4)) /*GPIO_150-
MMC3_WP*/\
Best regards,
Elvis
--
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:WDT:Enable support for IVA and SECURE
Hald, Ulrik Bech u...@ti.com writes:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, June 09, 2009 9:47 AM
To: Hald, Ulrik Bech
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/3] OMAP3:WDT:Enable support for IVA and SECURE
Ulrik Bech Hald u...@ti.com writes:
This patch enables the IVA and SECURE WDTs in the omap_wdt
driver for omap34xx family. SECURE will be available as /dev/watchdog1
HS/EMU devices and IVA will be available as /dev/watchdog3.
MPU will be available as /dev/watchdog2
For omap versions earlier than 34xx only MPU watchdog is present and
will be available as /dev/watchdog for backwards compatibility.
Signed-off-by: Ulrik Bech Hald u...@ti.com
---
drivers/watchdog/omap_wdt.c | 42 +++-
--
1 files changed, 35 insertions(+), 7 deletions(-)
mode change 100644 = 100755 drivers/watchdog/omap_wdt.c
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
[...]
static int omap_wdt_open(struct inode *inode, struct file *file)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
- void __iomem *base = wdev-base;
+ struct omap_wdt_dev *wdev;
+ void __iomem *base;
+
+ /* by default MPU wdt is present across omap family */
+ wdev = platform_get_drvdata(omap_wdt_dev[1]);
+
+ /* if multiple wdts, find match between device node and wdt device
*/
+ if (cpu_is_omap34xx()) {
+ int i;
+ for (i = 0; i NUM_WDTS; i++) {
+ if (omap_wdt_dev[i]) {
+ wdev = platform_get_drvdata(omap_wdt_dev[i]);
+ if (iminor(inode)
+ == wdev-omap_wdt_miscdev.minor)
+ break;
+ }
+ }
+ }
+
+ base = wdev-base;
Hmm, this does not look right to me. Any use of cpu_is_* in driver
code usually indicates that something is not quite right. This same
watchdog IP is used in some DaVinci family processors and needs to be
reused there.
I didn't do the miscdev research, but can't you get the pdev from the
miscdev.parent, and from there get the right wdev pointer from the
pdev.drvdata.
Otherwise, drop the cpu_is_* and just do inode checking all the time.
The way you've done it looks error prone to me.
I can't really see a to way pair the driver and device other than
doing inode/minor number checking , so I'll just go for the inode
checking without any dependency on cpu_is_xxx().
OK.
if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
return -EBUSY;
@@ -263,6 +283,7 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
struct resource *res, *mem;
struct omap_wdt_dev *wdev;
int ret;
+ static char wdt_name[32];
/* reserve static register mappings */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -271,7 +292,7 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
goto err_get_resource;
}
- if (omap_wdt_dev) {
+ if (omap_wdt_dev[pdev-id-1]) {
ret = -EBUSY;
goto err_busy;
}
@@ -318,8 +339,14 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
wdev-omap_wdt_miscdev.parent = pdev-dev;
wdev-omap_wdt_miscdev.minor = WATCHDOG_MINOR;
- wdev-omap_wdt_miscdev.name = watchdog;
wdev-omap_wdt_miscdev.fops = omap_wdt_fops;
+ wdev-omap_wdt_miscdev.name = watchdog;
+ if (cpu_is_omap34xx()) {
+ snprintf(wdt_name, sizeof(wdt_name), watchdog%d, pdev-id);
+ wdev-omap_wdt_miscdev.name = wdt_name;
+ if (pdev-id != 2)
+ wdev-omap_wdt_miscdev.minor = MISC_DYNAMIC_MINOR;
+ }
Again, red flag: cpu_is_*
It might be more consistent to use pdev-dev-name which is already of
the form watchdog.%d.
Not sure I follow. I don't see a name field in struct device, only
init_name.
Sorry, I meant dev-bus_id. Look at dev_set_name() which creates
a bus_id of the form (%s.%d, pdev-name, pdev-id)
Do you mean just using:
snprintf(wdt_name, sizeof(wdt_name), watchdog%d, pdev-id);
wdev-omap_wdt_miscdev.name = wdt_name;
Using pdev-id is ok, but that's what dev_set_name() does.
Note that if you decide to go this route, note that wdt_name doesn't
need to be static. The driver core will copy the name field the
misc_device. If it wasn't copying, you'd have all of the miscdev.name
fields ending up being the same thing since they are all assigned the
same pointer.
Kevin
...for all the WDT devices, despite how many are present?
Any reason not to use MISC_DYNAMIC_MINOR for all of them?
No particular reason other than I thought that retaining the use of
WATCHDOG_MINOR for the MPU WDT case would be appropriate. But it does make
the code cleaner to use only MISC_DYNAMIC_MINOR. I'll change it.
RE: [PATCHv3] DSPBRIDGE: Buffer size warning fixes
Hi,
-Original Message-
From: Ameya Palande [mailto:ameya.pala...@nokia.com]
Sent: Friday, June 05, 2009 8:03 AM
To: linux-omap@vger.kernel.org
Cc: Guzman Lugo, Fernando; Kanigeri, Hari
Subject: [PATCHv3] DSPBRIDGE: Buffer size warning fixes
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/pmgr/cod.c|3 ++-
drivers/dsp/bridge/rmgr/drv.c|5 +++--
drivers/dsp/bridge/services/regsup.c |6 --
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/cod.c b/drivers/dsp/bridge/pmgr/cod.c
index 6363f1e..2da46bd 100644
--- a/drivers/dsp/bridge/pmgr/cod.c
+++ b/drivers/dsp/bridge/pmgr/cod.c
@@ -628,7 +628,8 @@ DSP_STATUS COD_OpenBase(struct COD_MANAGER *hMgr, IN char
*pszCoffPath,
} else {
/* hang onto the library for subsequent sym table usage */
hMgr-baseLib = lib;
- strncpy(hMgr-szZLFile, pszCoffPath, COD_MAXPATHLENGTH);
+ strncpy(hMgr-szZLFile, pszCoffPath, COD_MAXPATHLENGTH - 1);
+ hMgr-szZLFile[COD_MAXPATHLENGTH - 1] = '\0';
}
return status;
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index a1ba19e..66e4a4d 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -1508,8 +1508,9 @@ DSP_STATUS DRV_RequestResources(u32 dwContext, u32
*pDevNodeString)
pszdevNode = MEM_Calloc(sizeof(struct DRV_EXT), MEM_NONPAGED);
if (pszdevNode) {
LST_InitElem(pszdevNode-link);
- strncpy((char *) pszdevNode-szString,
-(char *)dwContext, MAXREGPATHLENGTH);
+ strncpy(pszdevNode-szString,
+(char *)dwContext, MAXREGPATHLENGTH - 1);
+ pszdevNode-szString[MAXREGPATHLENGTH - 1] = '\0';
/* Update the Driver Object List */
*pDevNodeString = (u32)pszdevNode-szString;
LST_PutTail(pDRVObject-devNodeString,
diff --git a/drivers/dsp/bridge/services/regsup.c
b/drivers/dsp/bridge/services/regsup.c
index 5251b68..bec8e92 100644
--- a/drivers/dsp/bridge/services/regsup.c
+++ b/drivers/dsp/bridge/services/regsup.c
@@ -238,8 +238,10 @@ DSP_STATUS regsupSetValue(char *valName, void *pBuf, u32
dataSize)
/* No match, need to make a new entry */
/* First check to see if we can make any more entries. */
if (pRegKey-numValueEntries BRIDGE_MAX_NUM_REG_ENTRIES) {
- strncpy(pRegKey-values[pRegKey-numValueEntries].name,
- valName, BRIDGE_MAX_NAME_SIZE);
+ char *tmp_name =
+ pRegKey-values[pRegKey-numValueEntries].name;
+ strncpy(tmp_name, valName, BRIDGE_MAX_NAME_SIZE - 1);
+ tmp_name[BRIDGE_MAX_NAME_SIZE - 1] = '\0';
pRegKey-values[pRegKey-numValueEntries].pData =
MEM_Alloc(dataSize, MEM_NONPAGED);
if (pRegKey-values[pRegKey-numValueEntries].pData !=
--
1.6.2.4
Acked-by: Guzman Lugo Fernando x0095...@ti.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: [RFC][PATCH] DSPBRIDGE: Video Playback Cache Optimization
On Wed, Jun 10, 2009 at 12:39 AM, Ramirez Luna, Omaromar.rami...@ti.com wrote:
Hi,
Could you please comment on this patch.
From: Sripal Bagadia baga...@ti.com
Date: Tue, 9 Jun 2009 16:05:09 -0500
Subject: [PATCH] DSPBRIDGE: Video Playback Cache Optimization
Avoid get_user_pages cache flush overheads for uncached reserved
buffers (e.g. display camera buffers).
Signed-off-by: Sripal Bagadia baga...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index 7a9603d..a2f32e8 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -1461,7 +1461,9 @@ static DSP_STATUS WMD_BRD_MemMap(struct
WMD_DEV_CONTEXT *hDevContext,
goto func_cont;
}
- if (vma-vm_flags VM_IO) {
+ if ((vma-vm_flags VM_IO) | ((vma-vm_flags VM_RESERVED)
+ (~pgprot_val(vma-vm_page_prot) L_PTE_CACHEABLE)
+ (~pgprot_val(vma-vm_page_prot) L_PTE_BUFFERABLE))) {
L_PTE_BUFFERABLE is obsolete, isn't it? L_PTE_MT_BUFFERABLE should be
used instead.
--
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: [RFC][PATCH] DSPBRIDGE: Video Playback Cache Optimization
Hi,
[sending as plain text to l-o]
Could you please comment on this patch.
From: Sripal Bagadia baga...@ti.com
Date: Tue, 9 Jun 2009 16:05:09 -0500
Subject: [PATCH] DSPBRIDGE: Video Playback Cache Optimization
Avoid get_user_pages cache flush overheads for uncached reserved
buffers (e.g. display camera buffers).
Signed-off-by: Sripal Bagadia baga...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index 7a9603d..a2f32e8 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -1461,7 +1461,9 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
goto func_cont;
}
- if (vma-vm_flags VM_IO) {
+ if ((vma-vm_flags VM_IO) | ((vma-vm_flags VM_RESERVED)
+ (~pgprot_val(vma-vm_page_prot) L_PTE_CACHEABLE)
+ (~pgprot_val(vma-vm_page_prot) L_PTE_BUFFERABLE))) {
numUsrPgs = ulNumBytes / PG_SIZE_4K;
mpuAddr = ulMpuAddr;
DBG_Trace(DBG_LEVEL4, WMD_BRD_MemMap:numOfActualTabEntries=%d,
--
1.6.2.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: MUSB Host problems
-Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Tuesday, June 09, 2009 1:28 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org Subject: Re: MUSB Host problems Pandita, Vikram wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Tuesday, June 09, 2009 12:46 PM To: linux-omap@vger.kernel.org Subject: MUSB Host problems I'm trying to get MUSB Host working on my 3530 platform (very Based on your description, its not MUSB but the USBHOST EHCI block that you want to get working. Sorry, mistaken terminology. Yes, I'm trying to get the host ECHI working. similar to the Beagle). When I startup, I get this message: Clock usbhost_48m_fck didn't enable in 10 tries This is bad Why? What does it mean? How do I fix it? The ehci driver on linux-omap works for Beagleboard and sdp. so this may not be a fatal problem What does this mean? How do I fix it? Currently, the USB subsystem finds the various hubs (ports 0-2). The OTG port (0) works great. When I plug in a device to USB-1, Is this a full speed device? it sees it, but immediately gives up :-( ehci-omap ehci-omap.0: GetStatus port 1 status 001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 1: status 0501 change 0001 hub 1-0:1.0: state 7 ports 3 chg 0002 evt hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s ehci-omap ehci-omap.0: port 1 full speed -- companion Looks like your device is getting recognized as a full speed. So EHCI cannot handle it. Odd, this is a high speed device (USB 2.0). I also tried a 2.0 hub, same result. What could confuse it like this? Is it PHY mode or TLL mode? If its PHY: then the transceiver used definitely matters. SDP has ISP1504 and Beagle board has SMSC phy The 60Mhz clock is fed from omap into the Transceiver (Input clocking mode). Only few phy's in market support this. You need to have OHCI driver built in which is not present in linux-omap code base. Do, how does one use an arbitrary device on the EHCI port? Must I use a 2.0 hub? ehci-omap ehci-omap.0: GetStatus port 1 status 003801 POWER OWNER sig=j CONNECT hub 1-0:1.0: port 1 not reset yet, waiting 50ms ehci-omap ehci-omap.0: GetStatus port 1 status 003002 POWER OWNER sig=se0 CSC hub 1-0:1.0: unable to enumerate USB device on port 1 hub 1-0:1.0: state 7 ports 3 chg evt 0002 hub 1-0:1.0: hub_suspend Then it's dead. Any ideas? Note: this is unproven hardware, I'm mostly looking for ideas on how to troubleshoot the problems. Have one side working: Say have EHCI working on SDP/Beagle and then connect your device to it. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: MUSB Host problems
On Wed, 10 Jun 2009 07:55:17 +0530 Pandita, Vikram vikram.pand...@ti.com wrote: similar to the Beagle). When I startup, I get this message: Clock usbhost_48m_fck didn't enable in 10 tries This is bad Why? What does it mean? How do I fix it? The ehci driver on linux-omap works for Beagleboard and sdp. so this may not be a fatal problem Actually it's currently broken but issue is known: http://marc.info/?l=linux-omapm=124419824625121w=2 -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
