Re: [PATCH] ARM: OMAP3: Initialize XCCR and RCCR McBSP registersfor McBSP DAI driver
- Original Message -
From: Tony Lindgren t...@atomide.com
To: Lopez Cruz, Misael x0052...@ti.com
Cc: linux-omap@vger.kernel.org; Pandita, Vikram vikram.pand...@ti.com
Sent: Thursday, December 18, 2008 7:11 PM
Subject: Re: [PATCH] ARM: OMAP3: Initialize XCCR and RCCR McBSP registersfor
McBSP DAI driver
Hi,
* Lopez Cruz, Misael x0052...@ti.com [081218 12:16]:
This patch enables XCCR and RCCR McBSP register writing in OMAP 24xx/34xx
platforms. It also explicitly initializes those registers to their default
values in ASoC McBSP DAI driver.
Can you please describe a bit what these registers do? It's impossible
for anybody to decipher without looking at the TRM right now.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |6 ++
arch/arm/plat-omap/mcbsp.c |4
sound/soc/omap/omap-mcbsp.c |4
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 6a0d1a0..5885f3a 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -231,11 +231,16 @@
#define XPBBLK(value) ((value)7) /* Bits 7:8 */
/*** McBSP XCCR bit definitions
*/
+#define EXTCLKGATE 0x8000
+#define PPCONNECT 0x4000
+#define DXENDLY(value) ((value)12) /* Bits 12:13 */
+#define XFULL_CYCLE 0x0800
#define DILB 0x0020
#define XDMAEN 0x0008
#define XDISABLE 0x0001
/** McBSP RCCR bit definitions
*/
+#define RFULL_CYCLE 0x0800
#define RDMAEN 0x0008
#define RDISABLE 0x0001
@@ -267,6 +271,8 @@ struct omap_mcbsp_reg_cfg {
u16 rcerh;
u16 xcerg;
u16 xcerh;
+ u16 xccr;
+ u16 rccr;
};
i believe these register width should be defined as 32 bits instead of 16,
while read/write function will take care 16 or 32 bit write
depending on cpu.
typedef enum {
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index af33fc7..d71b30b 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -173,6 +173,10 @@ void omap_mcbsp_config(unsigned int id, const struct
omap_mcbsp_reg_cfg *config)
OMAP_MCBSP_WRITE(io_base, MCR2, config-mcr2);
OMAP_MCBSP_WRITE(io_base, MCR1, config-mcr1);
OMAP_MCBSP_WRITE(io_base, PCR0, config-pcr0);
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ OMAP_MCBSP_WRITE(io_base, XCCR, config-xccr);
+ OMAP_MCBSP_WRITE(io_base, RCCR, config-rccr);
+ }
}
EXPORT_SYMBOL(omap_mcbsp_config);
You can do the above with cpu_class_is_omap2() instead. Might be worth
checking that these registers are available on 2420 too.
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8485a8a..2e7000d 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -295,6 +295,10 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
regs-spcr1 |= RINTM(3);
regs-rcr2 |= RFIG;
regs-xcr2 |= XFIG;
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ regs-xccr = DXENDLY(1) | XDMAEN;
+ regs-rccr = RFULL_CYCLE | RDMAEN;
+ }
switch (fmt SND_SOC_DAIFMT_FORMAT_MASK) {
case SND_SOC_DAIFMT_I2S:
--
I agree with Jarkko's comment, the ASoC change should go via alsa list
as a separate patch.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: McBSP register question
- Original Message - From: Jason Marini jason.mar...@gmail.com To: linux-omap@vger.kernel.org Sent: Friday, December 12, 2008 11:51 PM Subject: McBSP register question Looking at the latest git head, I see that omap_mcbsp_pollwrite() and omap_mcbsp_pollread() improperly use readw() and writew() instead of OMAP_MCBSP_READ() and OMAP_MCBSP_WRITE() in the file arch/arm/plat-omap/mcbsp.c. But while I was editing this file, I also saw writes to OMAP_MCBSP_REG_DXR1, which is #define'd for ARCH_OMAP_34XX and ARCH_OMAP_24XX to be at an offset of 0x0C. The McBSP section of the TRM for the OMAP34xx has no mention of any registers existing at this offset. Why is this DXR1 and not just DXR? It so happens that McBSP on 2420 has DXR1 and DXR2 registers, but not on omap2430/34xx. To provide multi-omap suport and avoid ifdefs dxr1/2 and drr1/2 has been retained along with dxr and drr (same code mach-omap2/mcbsp.c supports 2420.) . -Jason Marini Associate Software Engineer Vocollect, Inc. -- 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][OMAPZOOM] OMAP3: Fix handling of McBSP registers XCCR and RCCR for OMAP2430/34xx
- Original Message -
From: Misael Lopez [EMAIL PROTECTED]
To: Gadiyar, Anand [EMAIL PROTECTED]
Cc: linux-omap@vger.kernel.org; Pandita, Vikram [EMAIL PROTECTED]
Sent: Friday, November 21, 2008 11:55 AM
Subject: Re: [PATCH][OMAPZOOM] OMAP3: Fix handling of McBSP registers XCCR and
RCCR for OMAP2430/34xx
@@ -403,8 +408,10 @@ struct omap_mcbsp_reg_cfg {
u16 rcerh;
u16 xcerg;
u16 xcerh;
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
u16 xccr;
u16 rccr;
+#endif
};
Won't this cause a compilation break on non-2430/34xx platforms
because you refer to these variables below?
True... I didn't consider that. Then for non-2430/34xx platforms,
having those registers in the structure but avoiding to write to them
is enough, correct? or any other alternative?
Since you write those registers conditionally for 2430/34xx, i guess removing
ifdef should do..
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: i2c-omap: Fix standard and fast mode prescalers
I had tested twl4030 at 3.4 Mbps couple of months back and it was working fine with current settings. It wasn't a rigorous testing though. - Original Message - From: Felipe Balbi [EMAIL PROTECTED] To: David Brownell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-omap@vger.kernel.org Sent: Saturday, November 15, 2008 3:16 AM Subject: Re: [PATCH] i2c: i2c-omap: Fix standard and fast mode prescalers On Fri, Nov 14, 2008 at 12:08:10PM -0800, David Brownell wrote: On Friday 14 November 2008, Felipe Balbi wrote: On Fri, Nov 14, 2008 at 11:45:30AM -0800, David Brownell wrote: And should it let at least some boards talk to their TWL chips at 3.4 MBit/sec (top speed for standard highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)? I've always wondered why all the boards configured those links to be seemingly slower than allowed ... I think it came from board-3430sdp.c So you're saying there was *never* a need for that slowdown, and everyone was just copying an existing buglet? I know I didn't make time to test whether faster speeds would work ... but had expected there was a reason, at some point, for that detuning. There was a need. But I think it should be fixed by now. I shall test tw5030 with 3.4Mbit/sec on monday. Will report. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [OMAPZOOM] Lower i2c speed on bus 1 for LDP.
- Original Message -
From: Dominic Curran [EMAIL PROTECTED]
To: linux-omap@vger.kernel.org
Sent: Thursday, November 13, 2008 1:51 AM
Subject: [PATCH 1/3] [OMAPZOOM] Lower i2c speed on bus 1 for LDP.
Resending patch with more descriptive comment.
Lower i2c bus 1 speed to 400KHz for LDP.
At 2600KHz i2c reads from twl4030 keypad driver are returning
incorrect data. Reason unknown. Lowering bus speed as temporary
fix to get LDP keypad working.
Signed-off-by: Dominic Curran [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-ldp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index d889ce8..b2e8c9c 100755
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -797,7 +797,7 @@ static struct i2c_board_info __initdata
ldp_i2c_boardinfo_2[] = {
static int __init omap_i2c_init(void)
{
- omap_register_i2c_bus(1, 2600, ldp_i2c_boardinfo,
+ omap_register_i2c_bus(1, 400, ldp_i2c_boardinfo,
ARRAY_SIZE(ldp_i2c_boardinfo));
Last time i checked we were getting few errors (returning incorrect values) even
at 400k , and no error at 100k.
Have you seen any at 400k?
omap_register_i2c_bus(2, 100, ldp_i2c_boardinfo_2,
ARRAY_SIZE(ldp_i2c_boardinfo_2));
--
1.5.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: i2c-omap: Fix BUFSTAT_REG reading
- Original Message -
From: [EMAIL PROTECTED]
To: linux-omap@vger.kernel.org
Cc: Eero Nurkkala [EMAIL PROTECTED]
Sent: Tuesday, November 11, 2008 12:21 PM
Subject: [PATCH] i2c: i2c-omap: Fix BUFSTAT_REG reading
From: Eero Nurkkala [EMAIL PROTECTED]
The amount of bytes to receive is read from wrong
place. It is the 6 bits starting from the bit 8 from
BUFSTAT_REG that indicate this amount. Not the 8 LSB:s.
6 LSB:s are used for the TX buffer.
Signed-off-by: Eero Nurkkala [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-omap.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a999606..f15668d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -621,8 +621,9 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (stat OMAP_I2C_STAT_RRDY)
num_bytes = dev-fifo_size;
else
- num_bytes = omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG);
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG)
+ 8) 0x3F;
}
I believe Anding by 0x3F will apply to transmit also.
while (num_bytes) {
num_bytes--;
--
1.6.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] McBSP DMA support for 34xx
- Original Message - From: Jarkko Nikula [EMAIL PROTECTED] To: ext shekhar, chandra [EMAIL PROTECTED] Cc: Tony Lindgren [EMAIL PROTECTED]; linux-omap@vger.kernel.org Sent: Wednesday, September 10, 2008 4:44 PM Subject: Re: [PATCH 1/2] McBSP DMA support for 34xx On Wed, 10 Sep 2008 15:47:34 +0530 ext shekhar, chandra [EMAIL PROTECTED] wrote: Most importantly, 4 McBSP buffer ( To save power, for 34xx). OMAP3430 McBSP interface 2 has 5k buffer for audio. handling of this buffer should be specific to McBSP. Actually it's not specific to McBSP only. I haven't paid attention into these HW buffering issues but they have an effect. Like - IRCC ALSA expects that playback/record is really stopped when trigger callback returns - How HW buffering affects pointer callback? Some low-latency audio algorithms require that buffer position is known very precisely. E.g. if modifying already queued audio buffer content but which is not played out yet This harware buffer is not user accessible, but during data transfer it is related to dma transfer. During data transfer instead of element sync, packet sync data transfer can be used. DMA request length can be configured buffer threshold and packet sync transfer can be used instead of element sync. Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] McBSP DMA support for 34xx
- Original Message - From: Jarkko Nikula [EMAIL PROTECTED] To: ext chandra shekhar [EMAIL PROTECTED] Cc: linux-omap@vger.kernel.org Sent: Thursday, August 28, 2008 4:22 PM Subject: Re: [PATCH 1/2] McBSP DMA support for 34xx On Thu, 28 Aug 2008 13:56:00 +0530 (IST) ext chandra shekhar [EMAIL PROTECTED] wrote: This patch supports DMA chaining mode and one time configuration for entire transfer to improve performance. Signed-off-by: chandra shekhar [EMAIL PROTECTED] --- arch/arm/mach-omap2/mcbsp.c | 702 +- arch/arm/plat-omap/mcbsp.c| 19 - include/asm-arm/arch-omap/mcbsp.h | 127 +- 3 files changed, 811 insertions(+), 37 deletions(-) Hi What's the expected use case for DMA chaining mode or existing driver which would get improved performance? There should have some reason why this amount of new lines should be added. current McBSP ( arch/arm/plat-omap/mcbsp.c) code request and releases dma channel for each transfer . so there is latency involved. Chaining help with smooth audio play because we can enque the buffer while another transfer is ongoing. Also ideally this should cover also OMAP1's from 16xx onward since they can link DMA channels together as well? Current code might even work for 16xx and later versions for 16 bit data. ( or can be extended to work on 16xx and later versions) but i dont have board or TRM to check for any changes in DMA subsytem or McBSP. better to play safe. 2430 onwards McBSP dxr/drr is 32 bits, which allows 24 bit mono/stereo transfer easily. if we had to have 16 bit dxr1,2/drr1,2 then we will have to perform the manipulation on data for 24 bit ops. we will have to consider all the options before extending it to 16xx. Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP AIC23
- Original Message - From: Hunter, Jon [EMAIL PROTECTED] To: Shekhar, Chandra [EMAIL PROTECTED]; Yuri Jaeger Monti [EMAIL PROTECTED]; linux-omap@vger.kernel.org Sent: Wednesday, August 13, 2008 8:20 AM Subject: RE: OMAP AIC23 Hi Chandra, i have a question, why a client is modifying mcbsp registers. There is a mcbsp config function (omap_mcbsp_config) exported which you can use to configure mcbsp registers. if its an absolute necessity you can use omap_mcbsp_read and omap_mcbsp_write function. which are defined in arch/arm/plat-omap/mcbsp.c. but you need to pass full register name, like OMAP_MCBSP_REG_SPCR1 instead of just SPCR1 ( 'SPCR1' undeclared error). Looking at the source file drivers/i2c/chips/tlv320aic23.c the function omap_mcbsp3_aic23_clock_init() is enabling the McBSP sample rate generator in order to generate the 12MHz system clock to the aic23. I believe that this needs to be done in order to configure the aic23. The good news is that there appears to be a simple fix. All we need to do is move the definitions of the macros OMAP_MCBSP_READ and OMAP_MCBSP_WRITE from mcbsp.c to the header include/asm-arm/arch-omap/mcbsp.h Look like this should be doable. but we will have two read/write defs in header. one will be Macro and other will be function, both mapping to same code. Doing this and making a couple other minor changes I am now able to build the alsa driver successfully for the omap5912 osk. I will submit a patch to the list. Let me know what you think. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP AIC23
Hi, answers below. - Original Message - From: Yuri Jaeger Monti [EMAIL PROTECTED] To: linux-omap@vger.kernel.org Sent: Tuesday, August 12, 2008 12:51 AM Subject: OMAP AIC23 Dear fellows, I'm having some errors trying to compile the current kernel version for OMAP5912 on AIC23: ... CC drivers/i2c/i2c-core.o CC drivers/i2c/i2c-dev.o LD drivers/i2c/algos/built-in.o CC drivers/i2c/busses/i2c-omap.o LD drivers/i2c/busses/built-in.o CC drivers/i2c/chips/tps65010.o CC drivers/i2c/chips/tlv320aic23.o drivers/i2c/chips/tlv320aic23.c: In function 'omap_mcbsp3_aic23_clock_init': drivers/i2c/chips/tlv320aic23.c:113: error: implicit declaration of function 'OMAP_MCBSP_WRITE' Recently there wre some changes in McBSP driver for multi-omap support. Earlier read/write calls used to be defined as a macro and now it has been converted to a function, hence the compilation error (implicit declaration of function 'OMAP_MCBSP_WRITE') . you can look for recent patches for arch/arm/plat-omap/mcbsp.c file. i have a question, why a client is modifying mcbsp registers. There is a mcbsp config function (omap_mcbsp_config) exported which you can use to configure mcbsp registers. if its an absolute necessity you can use omap_mcbsp_read and omap_mcbsp_write function. which are defined in arch/arm/plat-omap/mcbsp.c. but you need to pass full register name, like OMAP_MCBSP_REG_SPCR1 instead of just SPCR1 ( 'SPCR1' undeclared error). drivers/i2c/chips/tlv320aic23.c:113: error: 'SPCR1' undeclared (first use in this function) drivers/i2c/chips/tlv320aic23.c:113: error: (Each undeclared identifier is reported only once drivers/i2c/chips/tlv320aic23.c:113: error: for each function it appears in.) drivers/i2c/chips/tlv320aic23.c:114: error: 'SPCR2' undeclared (first use in this function) drivers/i2c/chips/tlv320aic23.c:117: error: 'PCR0' undeclared (first use in this function) drivers/i2c/chips/tlv320aic23.c:120: error: 'SRGR1' undeclared (first use in this function) drivers/i2c/chips/tlv320aic23.c:121: error: 'SRGR2' undeclared (first use in this function) drivers/i2c/chips/tlv320aic23.c:124: error: implicit declaration of function 'OMAP_MCBSP_READ' make[3]: *** [drivers/i2c/chips/tlv320aic23.o] Error 1 make[2]: *** [drivers/i2c/chips] Error 2 make[1]: *** [drivers/i2c] Error 2 make: *** [drivers] Error 2 Anyone know what could this be? Thanks! -- Yuri Jaeger Monti The Catholic University at Porto Alegre - PUCRS (51) 3320.3500 Ramal #7696 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] McBSP preamble patch for 34xx support,
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/mcbsp.c 2008-08-07
16:39:51.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/mcbsp.c 2008-08-07
16:45:00.0 +0530
@@ -29,9 +29,31 @@
struct omap_mcbsp **mcbsp_ptr;
int omap_mcbsp_count;
+int mcbsp_32_bit_ops;
+
+void omap_mcbsp_write(u32 io_base, u16 reg, u32 val)
+{
+ if (!mcbsp_32_bit_ops)
+ __raw_writew((u16)val, io_base + reg);
+ else
+ __raw_writel(val, io_base + reg);
+}
+
+int omap_mcbsp_read(u32 io_base, u16 reg)
+{
+ if (!mcbsp_32_bit_ops)
+ return __raw_readw(io_base + reg);
+ else
+ return __raw_readl(io_base + reg);
+}
+
The 16 vs 32-bit test above would be better done with cpu_is_omap2420()
than setting mcbsp_32_bit_ops. If 2420 is not selected, the test gets
optimized out as cpu_is_omap2420() is defined as 0.
Regards,
Tony
If i put a cpu check here then i will have to put either (cpu_class_is_omap1
|| cpu_is_omap2420) check , or
!( cpu_is_omap2430) !(cpu_is_omap34xx) - for 16 bit ops.
i am not sure which one will be more optimized as in the second case we will
have
a logical operator as well as cpu check. while in the first case we have
just a varable check.
Let me know if i am missing something.
+#define OMAP_MCBSP_READ(base, reg) \
+ omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg)
+#define OMAP_MCBSP_WRITE(base, reg, val) \
+ omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val)
#define omap_mcbsp_check_valid_id(id) (id omap_mcbsp_count)
-#define id_to_mcbsp_ptr(id) mcbsp_ptr[id];
+#define id_to_mcbsp_ptr(id) mcbsp_ptr[id];
static void omap_mcbsp_dump_reg(u8 id)
{
Index: linux-omap-2.6/include/asm-arm/arch-omap/mcbsp.h
===
--- linux-omap-2.6.orig/include/asm-arm/arch-omap/mcbsp.h 2008-08-07
16:41:17.0 +0530
+++ linux-omap-2.6/include/asm-arm/arch-omap/mcbsp.h 2008-08-07
16:45:00.0 +0530
@@ -139,10 +139,6 @@
#endif
-#define OMAP_MCBSP_READ(base, reg) __raw_readw((base) +
OMAP_MCBSP_REG_##reg)
-#define OMAP_MCBSP_WRITE(base, reg, val) __raw_writew((val), (base) +
OMAP_MCBSP_REG_##reg)
-
-
/** McBSP SPCR1 bit definitions
***/
#define RRST 0x0001
#define RRDY 0x0002
@@ -369,6 +365,7 @@
};
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count;
+extern int mcbsp_32_bit_ops;
int omap_mcbsp_init(void);
void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data
*config,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About to tag v2.6.26-omap1, patch queue deleted, please checkand repost
Hi, first - print is misleading, it should be i2c tarnsmit underflow. I2C transmit underflow is because of interrupt handler error. There was a patch to correct nack error ( ack for devices which are not present) which also removed some continue statement. now a race condition arises where even xdr and xudf is simultaneously generated. even if xdr is handled print goes to xudf and we get the print and hence error in return. so it might happen that ur data is transferred but u get error in return. i will send a patch by tomorrow to fix this Regards Chandra Shekhar - Original Message - From: Tony Lindgren [EMAIL PROTECTED] To: David Brownell [EMAIL PROTECTED] Cc: linux-omap@vger.kernel.org Sent: Thursday, August 07, 2008 4:27 PM Subject: Re: About to tag v2.6.26-omap1, patch queue deleted, please checkand repost * David Brownell [EMAIL PROTECTED] [080807 02:30]: On Tuesday 05 August 2008, Tony Lindgren wrote: Also please check that things work for your board, let's try to tag v2.6.26-omap1 within next few days so we can move on again. Two problems on the OSK5912: - cpufreq oopses on boot - continuous i2c overflow errors ISTR both of these bugs are in mainline too. I'd say the I2C regression is higher priority. Hmm, I wonder what has broken I2C? Anyways, let's fix these regressions before tagging. Tony - Dave CPUFREQ oopsing 5Linux version 2.6.26-omap1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53)) #186 PREEMPT Wed Aug 6 16:12:29 PDT 2008 CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177 Machine: TI-OSK Memory policy: ECC disabled, Data cache writeback 7On node 0 totalpages: 8192 7 DMA zone: 64 pages used for memmap 7 DMA zone: 0 pages reserved 7 DMA zone: 8128 pages, LIFO batch:0 7 Normal zone: 0 pages used for memmap 7 Movable zone: 0 pages used for memmap OMAP1611b revision 2 handled as 16xx id: 26058c80eb051c15 6SRAM: Mapped pa 0x2000 to va 0xd700 size: 0x10 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 5Kernel command line: console=ttyS0,115200 mem=32M ip=dhcp root=/dev/nfs i2c_omap.clock=400 3Unknown boot option `i2c_omap.clock=400': ignoring Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2833 ARM_CKCTL: 0x2000 6Clocking rate (xtal/DPLL1/MPU): 12.0/192.0/192.0 MHz Total of 128 interrupts in 4 interrupt banks 6OMAP GPIO hardware version 1.0 4MUX: initialized M7_1610_GPIO62 PID hash table entries: 128 (order: 7, 512 bytes) Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1920 bytes 6Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) 6Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) 6Memory: 32MB = 32MB total 5Memory: 26936KB available (2476K code, 2919K data, 104K init) 6SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 7Calibrating delay loop... 94.82 BogoMIPS (lpj=474112) Mount-cache hash table entries: 512 6CPU: Testing write buffer coherency: ok 6net_namespace: 256 bytes 6NET: Registered protocol family 16 4MUX: initialized M19_1610_CAM_RSTZ 4MUX: initialized Y15_1610_CAM_OUTCLK 4MUX: initialized H19_1610_CAM_EXCLK 4MUX: initialized W13_1610_CCP_CLKM 4MUX: initialized Y12_1610_CCP_CLKP 4MUX: initialized W14_1610_CCP_DATAP 4MUX: initialized N20_1610_GPIO11 4MUX: initialized P20_1610_GPIO4 4MUX: initialized PWL 6OMAP DMA hardware version 1 6DMA capabilities: 000c::01ff:003f:007f 6omap_dsp_init() done 1Unable to handle kernel NULL pointer dereference at virtual address 1pgd = c0004000 1[] *pgd= Internal error: Oops: 5 [#1] PREEMPT Modules linked in: CPU: 0Not tainted (2.6.26-omap1 #186) PC is at wq_per_cpu+0xc/0x14 LR is at queue_delayed_work_on+0x90/0x124 pc : [c005068c]lr : [c00510f0]psr: 6013 sp : c1c21dbc ip : c1c21dcc fp : c1c21dc8 r10: 0292 r9 : 0001 r8 : r7 : r6 : c0561c20 r5 : r4 : c0561c04 r3 : 0001 r2 : r1 : r0 : Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 10004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc1c20260) Stack: (0xc1c21dbc to 0xc1c22000) 1da0: c1c21df0 1dc0: c1c21dcc c00510f0 c0050690 c0561be0 0292 c02aa654 c0561be0 c1c38840 1de0: c1c21e1c c1c21df4 c0175358 c0051070 c1c38840 1e00: 0001 c001c818 c1c21e38 c1c21e20 c0172e00 c017514c 1e20:
Re: [PATCH 11/21] ARM: OMAP: McBSP: Prepare for splitting intoomap1 and omap2 code
Hi,
i was about to send the same patch. it works fine for me.
chandra Shekhar
- Original Message -
From: Tony Lindgren [EMAIL PROTECTED]
To: Russell King - ARM Linux [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Eduardo Valentin
[EMAIL PROTECTED]; linux-omap@vger.kernel.org; Nikula Jarkko
(NRC/Helsinki) [EMAIL PROTECTED]
Sent: Monday, June 23, 2008 3:09 PM
Subject: Re: [PATCH 11/21] ARM: OMAP: McBSP: Prepare for splitting intoomap1
and omap2 code
* Tony Lindgren [EMAIL PROTECTED] [080617 11:43]:
* Russell King - ARM Linux [EMAIL PROTECTED] [080614 11:17]:
On Fri, Jun 06, 2008 at 06:30:43PM -0700, Tony Lindgren wrote:
+#if defined(CONFIG_OMAP_MCBSP) || defined(CONFIG_OMAP_MCBSP_MODULE)
+
+static struct platform_device
omap_mcbsp_devices[OMAP_MAX_MCBSP_COUNT];
+static int mcbsps_configured;
+
+void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data
*config,
+ int size)
+{
+ int i;
+
+ if (size OMAP_MAX_MCBSP_COUNT) {
+ printk(KERN_WARNING Registered too many McBSPs platform_data.
+ Using maximum (%d) available.\n,
+ OMAP_MAX_MCBSP_COUNT);
+ size = OMAP_MAX_MCBSP_COUNT;
+ }
+
+ for (i = 0; i size; i++) {
+ struct platform_device *new_mcbsp = omap_mcbsp_devices[i];
Any reason this can't use the platform_device_alloc() API rather than
having a static restriction on the number (coupled with the wastage of
space for smaller 'size's ?)
I agree, this should be allocated. Eduardo, any comments?
Here's updated patch that uses platform_device_alloc().
Tony
From 53f2999d681669df0645053dc572d97cda69823d Mon Sep 17 00:00:00 2001
From: Eduardo Valentin [EMAIL PROTECTED]
Date: Mon, 23 Jun 2008 12:37:30 +0300
Subject: [PATCH] ARM: OMAP: McBSP: Prepare for splitting into omap1 and
omap2 code
This patch transform mcbsp code to use platform data
from arch/arm/plat-omap/devices.c
It also gets ride of ifdefs on mcbsp.c code.
To do it, a platform data structure was defined.
Signed-off-by: Eduardo Valentin [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 4a53f9b..81002b7 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -24,6 +24,7 @@
#include asm/arch/mux.h
#include asm/arch/gpio.h
#include asm/arch/menelaus.h
+#include asm/arch/mcbsp.h
#if defined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
@@ -145,6 +146,53 @@ static inline void omap_init_kp(void) {}
#endif
/*-*/
+#if defined(CONFIG_OMAP_MCBSP) || defined(CONFIG_OMAP_MCBSP_MODULE)
+
+static struct platform_device **omap_mcbsp_devices;
+
+void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data
*config,
+ int size)
+{
+ int i;
+
+ if (size OMAP_MAX_MCBSP_COUNT) {
+ printk(KERN_WARNING Registered too many McBSPs platform_data.
+ Using maximum (%d) available.\n,
+ OMAP_MAX_MCBSP_COUNT);
+ size = OMAP_MAX_MCBSP_COUNT;
+ }
+
+ omap_mcbsp_devices = kzalloc(size * sizeof(struct platform_device *),
+ GFP_KERNEL);
+ if (!omap_mcbsp_devices) {
+ printk(KERN_ERR Could not register McBSP devices\n);
+ return;
+ }
+
+ for (i = 0; i size; i++) {
+ struct platform_device *new_mcbsp;
+ int ret;
+
+ new_mcbsp = platform_device_alloc(omap-mcbsp, i + 1);
+ if (!new_mcbsp)
+ continue;
+ new_mcbsp-dev.platform_data = config[i];
+ ret = platform_device_add(new_mcbsp);
+ if (ret) {
+ platform_device_put(new_mcbsp);
+ continue;
+ }
+ omap_mcbsp_devices[i] = new_mcbsp;
+ }
+}
+
+#else
+void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data
*config,
+ int size)
+{ }
+#endif
+
+/*-*/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/4] McBSP support for 34XX
thanks for the comments i will make the necessary changes (for your and tony's comments) and resend it asap. - Original Message - From: Jarkko Nikula [EMAIL PROTECTED] To: ext Chandra shekhar [EMAIL PROTECTED] Cc: linux-omap@vger.kernel.org Sent: Wednesday, June 18, 2008 12:46 PM Subject: Re: [RFC/PATCH 0/4] McBSP support for 34XX Hi, Here is a patch that adds support for McBSP on 34XX. It has been verified in digital loopback mode. Hi, I tested the set with N810 ASoC audio and still plays :-) Some comments. First, commit messages should more descriptive than McBSP support for 34XX for all of them. Like: 1. Add support for OMAP34xx McBSP ports 3-4 2. Fix register access width for OMAP34xx (this should be -rc patch?) 3. ... The patch includes the following features. 1. McBSP enabled in defconfig This should go as a separate patch since it is for 3430dsp only. 2. Supporting all the LP features. 3. Support of DMA chaining mode and one time configuration for entire transfer to improve performance. 4. Independent configurations and transfer of Rx and Tx 5. MCBSP data transfer in 8, 16 and 32 bit mode. I think we should have some expected use case for these before adding the features? 6. instead of mcbsp client configuring all the register, it allows clients to configure parameters like clk polarity, clk src and other parameters. This would be good direction. E.g. it's bit hacky how configuration is now done in sound/soc/omap/omap-mcbsp.c where McBSP register cache is have to use because all of the registers are written in once with omap_mcbsp_config. Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
