Re: [alsa-devel] [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Mon, Oct 12, 2009 at 09:17:41AM +0300, Eero Nurkkala wrote: Indeed. If I'm not totally wrong, the sidetone engineering is such, that the sinetones should be of constant volume (this may depend on the usecase). So, let's say we have the TPA6130 codec's volume used along with a sidetone: 1. A change in TPA6130 volume should lead to a change in the sidetone's gain (if it's enabled). The change of gain is directly related to the change in the TPA's volume. Could you go into more detail about why there should be a relationship between the two gains? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Mon, 2009-10-12 at 11:12 +0200, ext Mark Brown wrote: On Mon, Oct 12, 2009 at 09:17:41AM +0300, Eero Nurkkala wrote: Indeed. If I'm not totally wrong, the sidetone engineering is such, that the sinetones should be of constant volume (this may depend on the usecase). So, let's say we have the TPA6130 codec's volume used along with a sidetone: 1. A change in TPA6130 volume should lead to a change in the sidetone's gain (if it's enabled). The change of gain is directly related to the change in the TPA's volume. Could you go into more detail about why there should be a relationship between the two gains? As mentioned, in some (or most) cases the absolute sinetone level (dB) is expected constant. Even a volume change should not effect the sidetone level. Thus, if there's a change in volume, the sidetone gains should be readjusted. If that can happen automatically, that would be just nice =) I don't know whether there should be a relationship, but if there was, that'd be very useful. But it gets complicated as there may be several volume controls in the path. Anyway, that was just an idea that may just as well be ignored. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Mon, Oct 12, 2009 at 12:28:25PM +0300, Eero Nurkkala wrote: As mentioned, in some (or most) cases the absolute sinetone level (dB) is expected constant. Even a volume change should not effect the sidetone level. Thus, if there's a change in volume, the sidetone gains should be readjusted. If that can happen automatically, that would be just nice =) That's what you said, but could you please go into a bit more detail about why you beleive that this should be the case? Is there some hardware limitation here? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Mon, 2009-10-12 at 11:32 +0200, ext Mark Brown wrote: On Mon, Oct 12, 2009 at 12:28:25PM +0300, Eero Nurkkala wrote: As mentioned, in some (or most) cases the absolute sinetone level (dB) is expected constant. Even a volume change should not effect the sidetone level. Thus, if there's a change in volume, the sidetone gains should be readjusted. If that can happen automatically, that would be just nice =) That's what you said, but could you please go into a bit more detail about why you beleive that this should be the case? Is there some hardware limitation here? No HW limits here... it's all about the hmm, friendliness of sidetones. The more intense the side-tone, the less intensely the speaker talks. (June 12, 1948) [REF] So changing the headset volume should not make the speaker talk more/less intensely? Of course it all depends... this is just one aspect to this. [REF] LOUDNESS OF SPEAKING: THE EFFECT OF THE INTENSITY OF SIDE-TONE UPON THE INTENSITY OF THE SPEAKER Kenyon College Acoustic Laboratory Gambier, Ohio School of Aviation Medicine and Research N.A.S., Pensacola, Florida -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Mon, Oct 12, 2009 at 01:28:48PM +0300, Eero Nurkkala wrote: No HW limits here... it's all about the hmm, friendliness of sidetones. This is an application level issue. We've no way of determining within the drivers if a given path is actually being used as a real sidetone or if it is being used for some other purpose. As far as the drivers are concerned these are unrelated controls. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Fri, Oct 09, 2009 at 08:09:27AM +0300, Eero Nurkkala wrote: On Thu, 2009-10-08 at 15:17 +0200, ext Mark Brown wrote: This stuff, particularly the enable, probably wants to be pushed out via an ALSA API rather than via random sysfs stuff. It'd be better to publish a control API here and then use that from within ALSA. Hmm. What would be the way to transfer 128 x s16 words; is there an ALSA control for something like that already ? IIRC correctly, the max bytesize per control is (or used to be) something like 256 bytes or so. So that gets right at it. (that's the sidetone 128 tap FIR in question) For things like the FIR you probably don't want to expose the entire table directly to user space. Depending on the typical usage it may be that platform data is the appropriate mechanism, with some simpler thing presented to applications allowing switching between a limited set of settings. sysfs may end up being the best option for the FIR setup. My main concern here is that the control goes into the ALSA domain so that the audio drivers know what's going on with these sidetone paths, particular in terms of the routing. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
Add Sidetone feature to mcbsp instances 2 and 3 on OMAP3 based devices.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/mcbsp.c |2 +
arch/arm/plat-omap/include/mach/mcbsp.h | 43
arch/arm/plat-omap/mcbsp.c | 379 ++-
3 files changed, 423 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index a846aa1..c5b4d33 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -132,6 +132,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
+ .phys_base_st = OMAP34XX_MCBSP2_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
@@ -141,6 +142,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
},
{
.phys_base = OMAP34XX_MCBSP3_BASE,
+ .phys_base_st = OMAP34XX_MCBSP3_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP3_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 7e9cae3..8ecc09d 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -49,6 +49,9 @@
#define OMAP34XX_MCBSP1_BASE 0x48074000
#define OMAP34XX_MCBSP2_BASE 0x49022000
+#define OMAP34XX_MCBSP2_ST_BASE0x49028000
+#define OMAP34XX_MCBSP3_BASE 0x49024000
+#define OMAP34XX_MCBSP3_ST_BASE0x4902A000
#define OMAP34XX_MCBSP3_BASE 0x49024000
#define OMAP34XX_MCBSP4_BASE 0x49026000
#define OMAP34XX_MCBSP5_BASE 0x48096000
@@ -147,6 +150,15 @@
#define OMAP_MCBSP_REG_WAKEUPEN0xA8
#define OMAP_MCBSP_REG_XCCR0xAC
#define OMAP_MCBSP_REG_RCCR0xB0
+#define OMAP_MCBSP_REG_SSELCR 0xBC
+
+#define OMAP_ST_REG_REV0x00
+#define OMAP_ST_REG_SYSCONFIG 0x10
+#define OMAP_ST_REG_IRQSTATUS 0x18
+#define OMAP_ST_REG_IRQENABLE 0x1C
+#define OMAP_ST_REG_SGAINCR0x24
+#define OMAP_ST_REG_SFIRCR 0x28
+#define OMAP_ST_REG_SSELCR 0x2C
#define AUDIO_MCBSP_DATAWRITE (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1)
#define AUDIO_MCBSP_DATAREAD (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1)
@@ -265,6 +277,24 @@
#define ENAWAKEUP 0x0004
#define SOFTRST0x0002
+/** McBSP SSELCR bit definitions ***/
+#define SIDETONEEN 0x0400
+
+/** McBSP Sidetone SYSCONFIG bit definitions ***/
+#define ST_AUTOIDLE0x0001
+
+/** McBSP Sidetone SGAINCR bit definitions */
+#define ST_CH1GAIN(value) ((value16)) /* Bits 16:31 */
+#define ST_CH0GAIN(value) (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SFIRCR bit definitions **/
+#define ST_FIRCOEFF(value) (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SSELCR bit definitions **/
+#define ST_COEFFWRDONE 0x0004
+#define ST_COEFFWREN 0x0002
+#define ST_SIDETONEEN 0x0001
+
/** McBSP DMA operating modes **/
#define MCBSP_DMA_MODE_ELEMENT 0
#define MCBSP_DMA_MODE_THRESHOLD 1
@@ -375,10 +405,22 @@ struct omap_mcbsp_platform_data {
u16 rx_irq, tx_irq;
struct omap_mcbsp_ops *ops;
#ifdef CONFIG_ARCH_OMAP34XX
+ /* Sidetone block for McBSP 2 and 3 */
+ unsigned long phys_base_st;
u16 buffer_size;
#endif
};
+struct omap_mcbsp_st_data {
+ void __iomem *io_base_st;
+ int enabled;
+ int running;
+ s16 taps[128]; /* Sidetone filter coefficients */
+ int nr_taps;/* Number of filter coefficients in use */
+ s16 ch0gain;
+ s16 ch1gain;
+};
+
struct omap_mcbsp {
struct device *dev;
unsigned long phys_base;
@@ -411,6 +453,7 @@ struct omap_mcbsp {
struct clk *iclk;
struct clk *fclk;
#ifdef CONFIG_ARCH_OMAP34XX
+ struct omap_mcbsp_st_data *st_data;
int dma_op_mode;
u16 max_tx_thres;
u16 max_rx_thres;
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 88ac976..9baa4b4 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -26,6 +26,9 @@
#include mach/dma.h
#include mach/mcbsp.h
+#ifdef CONFIG_ARCH_OMAP34XX
+#include ../mach-omap2/cm-regbits-34xx.h
+#endif
struct omap_mcbsp **mcbsp_ptr;
int omap_mcbsp_count;
@@ -54,6 +57,11 @@ int omap_mcbsp_read(void __iomem
Re: [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Thu, Oct 08, 2009 at 02:58:52PM +0300, Eduardo Valentin wrote:
+static const struct attribute *sidetone_attrs[] = {
+ dev_attr_st_enable.attr,
+ dev_attr_st_taps.attr,
+ dev_attr_st_ch0gain.attr,
+ dev_attr_st_ch1gain.attr,
+ NULL,
+};
This stuff, particularly the enable, probably wants to be pushed out via
an ALSA API rather than via random sysfs stuff. It'd be better to
publish a control API here and then use that from within ALSA.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Thu, Oct 08, 2009 at 03:17:02PM +0200, Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:52PM +0300, Eduardo Valentin wrote:
+static const struct attribute *sidetone_attrs[] = {
+ dev_attr_st_enable.attr,
+ dev_attr_st_taps.attr,
+ dev_attr_st_ch0gain.attr,
+ dev_attr_st_ch1gain.attr,
+ NULL,
+};
This stuff, particularly the enable, probably wants to be pushed out via
an ALSA API rather than via random sysfs stuff. It'd be better to
publish a control API here and then use that from within ALSA.
I see. The thing is this mcbsp driver is kinda of odd driver.
It is currently a platform driver. And it is supposed to be not
restricted to audio things (even though it is currently used only
by audio). It does not export any alsa interface currently.
So, maybe we should rip off this sysfs things, export
symbols inside kernel and then export to user land somewhere else
from alsa code?
--
Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Thu, Oct 08, 2009 at 04:23:33PM +0300, Eduardo Valentin wrote: So, maybe we should rip off this sysfs things, export symbols inside kernel and then export to user land somewhere else from alsa code? Yes, that's what I'm suggesting. Provide an API to ALSA and then let ALSA worry about the control stuff. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Thu, 2009-10-08 at 15:17 +0200, ext Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:52PM +0300, Eduardo Valentin wrote:
+static const struct attribute *sidetone_attrs[] = {
+ dev_attr_st_enable.attr,
+ dev_attr_st_taps.attr,
+ dev_attr_st_ch0gain.attr,
+ dev_attr_st_ch1gain.attr,
+ NULL,
+};
This stuff, particularly the enable, probably wants to be pushed out via
an ALSA API rather than via random sysfs stuff. It'd be better to
publish a control API here and then use that from within ALSA.
Hmm. What would be the way to transfer 128 x s16 words; is there an ALSA
control for something like that already ? IIRC correctly, the max
bytesize per control is (or used to be) something like 256 bytes or so.
So that gets right at it. (that's the sidetone 128 tap FIR in question)
- Eero
--
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
