Re: [PATCH 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On 11/08/2012 01:29 PM, Grazvydas Ignotas wrote:
But I want to note that I'm currently trying to clean up the mess around
twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
is for driving the LED A/B outputs. We should have only these modules for
PWM/LED in twl-core:
TWL_MODULE_PWM - offset for PWM0ON register in twl4030 and PWM1ON for twl6030
TWL_MODULE_LED - offset for LEDEN register in twl4030 and LED_PWM_CTRL1
for twl6030
From here the driver can figure out what to do IMHO.
There's no need to have separate TWL 'modules' for:
TWL4030_BASEADD_PWM0
TWL4030_BASEADD_PWM1
TWL4030_BASEADD_PWMA
TWL4030_BASEADD_PWMB
Well all these seem to come from TRM, no hard feelings here too but if
you are going to remove them, probably worth adding a comment.
From the 'outside' of twl4030 we have: LEDA, LEDB, PWM0 and PWM1 pins. This is
more important from system integration point of view than what name the TRM
calls the PWM (PWMA) behind of the LEDA terminal for example.
At the end in the board file you will have to use something like this:
static struct pwm_lookup zoom_pwm_lookup[] = {
PWM_LOOKUP(twl-pwm, 0, leds_pwm, zoom::keypad), /* PWM0 */
PWM_LOOKUP(twl-pwm, 1, pwm-backlight, backlight), /* PWM1 */
PWM_LOOKUP(twl-pwm-led, 0, leds_pwm, zoom::blinking), /* LEDA */
};
I'll add comment to both the pwm-twl and pwm-twl-led driver for clarification.
--
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: [PATCH 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
On 11/07/2012 06:50 PM, Grazvydas Ignotas wrote:
+static int twl4030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+ if (ret 0) {
+ dev_err(chip-dev, %s: Failed to read GPBR1\n, pwm-label);
+ return ret;
+ }
+
+ val |= TWL4030_PWM_TOGGLE(pwm-hwpwm, TWL4030_PWMX_BITS);
In my experience doing it like this doesn't work reliably, i.e.
sometimes it just won't enable. I had to first set CLK_ENABLE bit, and
then ENABLE bit with separate i2c write. Perhaps it needs a cycle or
two of 32k clock or something (that doesn't seem to be documented
though).
Thanks, I'll change to the reliable sequence. I do not have HW where I can
test the twl4030 PWMs.
+
+ ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+ if (ret 0)
+ dev_err(chip-dev, %s: Failed to enable PWM\n, pwm-label);
+
+ return ret;
+}
+
+static void twl4030_pwm_disable(struct pwm_chip *chip, struct pwm_device
*pwm)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+ if (ret 0) {
+ dev_err(chip-dev, %s: Failed to read GPBR1\n, pwm-label);
+ return;
+ }
+
+ val = ~TWL4030_PWM_TOGGLE(pwm-hwpwm, TWL4030_PWMX_BITS);
Same problem here, I would sometimes get LED stuck at full brightness
after this, first clearing ENABLE and then CLK_ENABLE fixed it (we
have charger LED connected to PWM1 on pandora).
I would guessed that if we need special care we should have turned off CLK
followed by disabling the PWM.
I'll use the sequence you described in the next version.
+
+ ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+ if (ret 0)
+ dev_err(chip-dev, %s: Failed to disable PWM\n,
pwm-label);
+}
+
+static int twl4030_pwm_request(struct pwm_chip *chip, struct pwm_device
*pwm)
+{
+ struct twl_pwm_chip *twl = container_of(chip, struct twl_pwm_chip,
+ chip);
+ int ret;
+ u8 val, mask, bits;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_PMBR1_REG);
+ if (ret 0) {
+ dev_err(chip-dev, %s: Failed to read PMBR1\n, pwm-label);
+ return ret;
+ }
+
+ if (pwm-hwpwm) {
+ /* PWM 1 */
+ mask = TWL4030_GPIO7_VIBRASYNC_PWM1_MASK;
+ bits = TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1;
+ } else {
+ /* PWM 0 */
+ mask = TWL4030_GPIO6_PWM0_MUTE_MASK;
+ bits = TWL4030_GPIO6_PWM0_MUTE_PWM0;
+ }
+
+ /* Save the current MUX configuration for the PWM */
+ twl-twl4030_pwm_mux = ~mask;
+ twl-twl4030_pwm_mux |= (val mask);
Do we really need this mask clearing here? After probe twl4030_pwm_mux
should be zero, and if twl4030_pwm_request is called twice you don't
clear the important bits before |=, I think 'twl4030_pwm_mux = val
mask' would be better here.
I'm storing both PWM's state in the same variable, but in different offsets:
PWM0: bits 2-3
PWM1: bits 4-5
Probably it is over engineering to clear the relevant bits in the backup
storage, but better to be safe IMHO.
I would leave this part as it is.
--
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: [PATCH 3/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
On 11/07/2012 07:12 PM, Grazvydas Ignotas wrote:
+static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device
*pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = (duty_ns * TWL4030_LED_MAX) / period_ns;
+ u8 on_time;
+ u8 pwm_config[2];
+ int base, ret;
+
+ if (duty_cycle = TWL4030_LED_MAX)
+ on_time = TWL4030_LED_MAX;
+ else if (!duty_cycle)
+ on_time = TWL4030_LED_MAX - 1;
+ else
+ on_time = TWL4030_LED_MAX - duty_cycle;
+
+ base = pwm-hwpwm * 2 + TWL4030_PWMA_REG;
+
+ pwm_config[0] = on_time;
+ pwm_config[1] = TWL4030_LED_MAX;
+
+ ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
Shouldn't this use TWL4030_MODULE_PWMA and TWL4030_MODULE_PWMB as
first argument? I can guess it works your way too, but
TWL4030_MODULE_PWMx would match the TRM better.
I don't have strong opinion regarding to this. You mean changing from:
base = pwm-hwpwm * 2 + TWL4030_PWMA_REG;
ret = twl_i2c_write(TWL4030_MODULE_LED, pwm_config, base, 2);
to:
if (pwm-hwpwm)
module = TWL4030_MODULE_PWMB;
else
module = TWL4030_MODULE_PWMA;
ret = twl_i2c_write(module, pwm_config, 0, 2);
But I want to note that I'm currently trying to clean up the mess around
twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
is for driving the LED A/B outputs. We should have only these modules for
PWM/LED in twl-core:
TWL_MODULE_PWM - offset for PWM0ON register in twl4030 and PWM1ON for twl6030
TWL_MODULE_LED - offset for LEDEN register in twl4030 and LED_PWM_CTRL1
for twl6030
From here the driver can figure out what to do IMHO.
There's no need to have separate TWL 'modules' for:
TWL4030_BASEADD_PWM0
TWL4030_BASEADD_PWM1
TWL4030_BASEADD_PWMA
TWL4030_BASEADD_PWMB
--
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: [PATCH v2 1/2] ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type
Hi Benoit,
On 10/31/2012 12:09 PM, Cousson, Benoit wrote:
Hi Peter,
That's great you've have done that fix.
On 10/30/2012 12:24 PM, Peter Ujfalusi wrote:
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them in hwmod database.
Mmm, does it worth doing that for every resources considering that this is a
temporary situation and than only the DMA resources are an issue so far?
I think it is better to have nice API - even for a short term - than introduce
a new wrapper just to count the DMA resources.
Yes we only use this to either count all resources or to count the DMA
resources only, but the other options does not look better either:
1. omap_hwmod_count_dma_resources(struct omap_hwmod *oh)
2. omap_hwmod_count_resources(struct omap_hwmod *oh, bool dma_only)
--
Péter
Otherwise that looks fine to me and will allow a much smoother transition to
full DT.
Thanks,
Benoit
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 27
---
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +-
arch/arm/plat-omap/omap_device.c | 11 ---
3 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index b969ab1..a79c941 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3337,7 +3337,7 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
/**
* omap_hwmod_count_resources - count number of struct resources needed by
hwmod
* @oh: struct omap_hwmod *
- * @res: pointer to the first element of an array of struct resource to fill
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource array elements necessary to
* contain omap_hwmod @oh resources. Intended to be called by code
@@ -3350,20 +3350,25 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
* resource IDs.
*
*/
-int omap_hwmod_count_resources(struct omap_hwmod *oh)
+int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags)
{
-struct omap_hwmod_ocp_if *os;
-struct list_head *p;
-int ret;
-int i = 0;
+int ret = 0;
-ret = _count_mpu_irqs(oh) + _count_sdma_reqs(oh);
+if (flags IORESOURCE_IRQ)
+ret += _count_mpu_irqs(oh);
-p = oh-slave_ports.next;
+if (flags IORESOURCE_DMA)
+ret += _count_sdma_reqs(oh);
-while (i oh-slaves_cnt) {
-os = _fetch_next_ocp_if(p, i);
-ret += _count_ocp_if_addr_spaces(os);
+if (flags IORESOURCE_MEM) {
+int i = 0;
+struct omap_hwmod_ocp_if *os;
+struct list_head *p = oh-slave_ports.next;
+
+while (i oh-slaves_cnt) {
+os = _fetch_next_ocp_if(p, i);
+ret += _count_ocp_if_addr_spaces(os);
+}
}
return ret;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index b3349f7..48a6f5d 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -628,7 +628,7 @@ void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16
reg_offs);
u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs);
int omap_hwmod_softreset(struct omap_hwmod *oh);
-int omap_hwmod_count_resources(struct omap_hwmod *oh);
+int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
*res);
int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int
type,
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 7a7d1f2..915cf68 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -442,19 +442,21 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev)
/**
* omap_device_count_resources - count number of struct resource entries
needed
* @od: struct omap_device *
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource entries needed for this
* omap_device @od. Used by omap_device_build_ss() to determine how
* much memory to allocate before calling
* omap_device_fill_resources(). Returns the count.
*/
-static int omap_device_count_resources(struct omap_device *od)
+static int omap_device_count_resources(struct omap_device *od,
+ unsigned long flags)
{
int c = 0;
int i;
for (i = 0; i od-hwmods_cnt; i++)
-c += omap_hwmod_count_resources(od-hwmods[i]);
+c += omap_hwmod_count_resources(od-hwmods[i], flags);
pr_debug(omap_device: %s: counted %d
Re: [PATCHv2 12/12] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
Hi Paul,
On 10/30/2012 05:05 AM, Paul Walmsley wrote:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
The McPDM on OMAP4 can only receive its functional clock from an
off-chip source. This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C. This would
introduce a board dependency to the early hwmod code which it was not
designed to handle. Also, neither the driver for this off-chip clock
provider nor the I2C code is available early in boot when the hwmod
code is attempting to enable and reset IP blocks. This effectively
makes it impossible to enable and reset this device during hwmod init.
At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source. (This is true for almost
every IP block on the chip. As far as I know, McPDM is the only
exception.) If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state. Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.
This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag. This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Péter Ujfalusi peter.ujfal...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..7bddfa5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2125,6 +2125,14 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
.name = mcpdm,
.class = omap44xx_mcpdm_hwmod_class,
.clkdm_name = abe_clkdm,
+ /*
+ * It's suspected that the McPDM requires an off-chip main
+ * functional clock, controlled via I2C. This IP block is
+ * currently reset very early during boot, before I2C is
+ * available, so it doesn't seem that we have any choice in
+ * the kernel other than to avoid resetting it.
+ */
+ .flags = HWMOD_EXT_OPT_MAIN_CLK,
.mpu_irqs = omap44xx_mcpdm_irqs,
.sdma_reqs = omap44xx_mcpdm_sdma_reqs,
.main_clk = mcpdm_fck,
--
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: [PATCH 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
On 10/30/2012 11:33 AM, Peter Ujfalusi wrote:
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have more resources in
hwmod than in DT (to be able to append the DMA resource from hwmod).
To fix this issue we just examine the OF provided resources:
If we do not have resources we use hwmod to fill them.
If we have resources we check if we already able to recive DMA resource, if
no we only append the DMA resurce from hwmod to the OF provided ones.
In this way we can start removing hwmod data for devices which have their
resources correctly configured in DT without regressions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/omap_device.c | 80
+++-
1 file changed, 47 insertions(+), 33 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 915cf68..a8a9d08 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -560,55 +560,69 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
od-hwmods = hwmods;
od-pdev = pdev;
- /* Count all resources for the device */
- res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
- IORESOURCE_DMA |
- IORESOURCE_MEM);
/*
+ * Non-DT Boot:
+ * Here, pdev-num_resources = 0, and we should get all the
+ * resources from hwmod.
+ *
* DT Boot:
* OF framework will construct the resource structure (currently
* does for MEM IRQ resource) and we should respect/use these
* resources, killing hwmod dependency.
* If pdev-num_resources 0, we assume that MEM IRQ resources
* have been allocated by OF layer already (through DTB).
- *
- * Non-DT Boot:
- * Here, pdev-num_resources = 0, and we should get all the
- * resources from hwmod.
+ * As preparation for the future we examine the OF provided resources
+ * to see if we have DMA resources provided already. In this case
+ * there is no need to update the resources for the device, we use the
+ * OF provided ones.
*
* TODO: Once DMA resource is available from OF layer, we should
* kill filling any resources from hwmod.
*/
- if (res_count pdev-num_resources) {
- /* Allocate resources memory to account for new resources */
- res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
- if (!res)
- goto oda_exit3;
-
- /*
- * If pdev-num_resources 0, then assume that,
- * MEM and IRQ resources will only come from DT and only
- * fill DMA resource from hwmod layer.
- */
- if (pdev-num_resources pdev-resource) {
- dev_dbg(pdev-dev, %s(): resources already allocated
%d\n,
- __func__, res_count);
- memcpy(res, pdev-resource,
-sizeof(struct resource) * pdev-num_resources);
- _od_fill_dma_resources(od, res[pdev-num_resources]);
- } else {
- dev_dbg(pdev-dev, %s(): using resources from hwmod
%d\n,
- __func__, res_count);
- omap_device_fill_resources(od, res);
+ if (!pdev-num_resources) {
+ /* Count all resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA |
+ IORESOURCE_MEM);
+ } else {
+ /* Take a look if we already have DMA resource via DT */
+ for (i = 0; i pdev-num_resources; i++) {
+ struct resource *r = pdev-resource[i];
+
+ /* We have it, no need to touch the resources */
+ if (r-flags == IORESOURCE_DMA)
+ goto have_everything;
}
+ /* Count only DMA resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_DMA);
We have devices without DMA channel so we can skip the resource recreation for
them.
I'll resend the series with this update.
+ res_count += pdev-num_resources;
+ }
- ret = platform_device_add_resources(pdev, res, res_count);
- kfree(res);
+ /* Allocate resources memory to account for new resources */
+
Re: [PATCH 0/2] ARM: OMAP: hwmod/omapd_device: Fix for resource handling in DT boot
On 10/30/2012 12:25 PM, Paul Walmsley wrote: On Tue, 30 Oct 2012, Peter Ujfalusi wrote: Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure going to help us to clean up the OMAP5 hwmod database. It's definitely not 3.7 material, but will look at it for 3.8 merge window. The OMAP5 hwmod data isn't in mainline yet. True, it can wait till 3.8. -- 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: [PATCH] ARM: dts: OMAP: Move interrupt-parent to the root node to avoid duplication
On 10/24/2012 12:02 PM, Benoit Cousson wrote: The interrupt-parent attribute does not have to be added in each node since the DT framework will check for the parent as well to get it. Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the attributes from every nodes that were using it. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Vaibhav Hiremath hvaib...@ti.com Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Sebastien Guiriec s-guir...@ti.com Thanks Benoit, looks good from my side. Acked-by: Peter Ujfalusi peter.ujfal...@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: [PATCH] ARM/dts: omap3: Fix mcbsp2/3 hwmods to be able to probe the drivers for audio
Hi Tony,
On 10/18/2012 12:00 PM, Benoit Cousson wrote:
On 10/18/2012 11:25 AM, Peter Ujfalusi wrote:
Fixes the following errors:
[2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
[2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
Which is because we failed to link the sidetone hwmod for McBSP2/3. The
missing sidetone hwmod link will prevent omap_device_alloc() to append the
DMA resources since we - accidentally - end up having the same number of
resources provided from DT (IO/IRQ) as we have in hwmod for the McBSP ports
without the ST resources.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
Can you take this patch for -rc3?
Thanks,
Péter
Regards,
Benoit
---
Hi Tony, Benoit,
Can you please take this patch for 3.7 since if we boot with DT audio will
not
work on BeagleBoard and on boards which uses McBSP2 or 3 for audio.
Thank you,
Peter
arch/arm/boot/dts/omap3.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f38ea87..696e929 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -257,7 +257,7 @@
interrupt-names = common, tx, rx, sidetone;
interrupt-parent = intc;
ti,buffer-size = 1280;
-ti,hwmods = mcbsp2;
+ti,hwmods = mcbsp2, mcbsp2_sidetone;
};
mcbsp3: mcbsp@49024000 {
@@ -272,7 +272,7 @@
interrupt-names = common, tx, rx, sidetone;
interrupt-parent = intc;
ti,buffer-size = 128;
-ti,hwmods = mcbsp3;
+ti,hwmods = mcbsp3, mcbsp3_sidetone;
};
mcbsp4: mcbsp@49026000 {
--
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] dmaengine: omap-dma: Allow DMA controller to prefetch data
Hi, On 10/19/2012 01:33 AM, Russell King - ARM Linux wrote: I would suggest getting some feedback from the ASoC people first, before trying to invent new APIs to work around this stuff. If they can live with having prefetch enabled on OMAP then there isn't an issue here. If not, we need a solution to this. I do not believe that precisely stopping and starting playback across a suspend/resume event is really necessary (it's desirable but the world doesn't collapse if you miss a few samples.) It could be more of an issue for pause/resume though, but as I say, that's for ASoC people to comment on. There is another issue with the prefetch in audio: we tend to like to know the position of the DMA and also to know how much data we have stored in buffers, FIFOs. This information is used by userspace to do echo cancellation and also used by PA for example to do runtime mixing directly in the audio buffer. We have means to extract this information from McBSP for example (and from tlv320dac33 codec) but AFAIK this information can not be retrieved from sDMA. We could assume that the sDMA FIFO is kept full and report that as a 'delay' or do not account this information. For now I think the cyclic mode should not set the prefetch. If I recall right the cyclic mode is only used by audio at the moment. I'm merely pointing out here that we need their feedback here before deciding if there's anything further that needs to happen. Thanks Russell, I'll take a look at the implication of the prefetch for audio. -- 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: [PATCH 6/6] OMAPDSS: HDMI: Create platform device to support audio
On 10/16/2012 03:27 AM, Ricardo Neri wrote:
Creating the accessory devices, such as audio, from the HDMI driver
allows to regard HDMI as a single entity with audio an display
functionality. This intends to follow the design of drivers such
as MFD, in which a single entity handles the creation of the accesory
devices. Such devices are then used by domain-specific drivers; audio in
this case.
Also, this is in line with the DT implementation of HDMI, in which we will
have a single node to describe this feature of the OMAP SoC.
...
+ hdmi_aud_res[HDMI_AUDIO_MEM_RESOURCE].start = res-start;
+ hdmi_aud_res[HDMI_AUDIO_MEM_RESOURCE].end = res-end;
+ hdmi_aud_res[HDMI_AUDIO_MEM_RESOURCE].flags = IORESOURCE_MEM;
+
+ res = platform_get_resource(hdmi.pdev, IORESOURCE_DMA, 0);
+ if (!res) {
+ DSSERR(can't get IORESOURCE_DMA HDMI\n);
+ return -EINVAL;
+ }
+
+ /* Pass this resource to audio_pdev */
+ hdmi_aud_res[HDMI_AUDIO_DMA_RESOURCE].start = res-start;
+ hdmi_aud_res[HDMI_AUDIO_DMA_RESOURCE].end = res-end;
+ hdmi_aud_res[HDMI_AUDIO_DMA_RESOURCE].flags = IORESOURCE_DMA;
+
+ /* create platform device for HDMI audio driver */
+ hdmi.audio_pdev = platform_device_register_simple(
+ omap_hdmi_audio,
+ -1, hdmi_aud_res,
+
ARRAY_SIZE(hdmi_aud_res));
Should you also update arch/arm/mach-omap2/devices.c to not register the same
device?
When we do not boot with DT devices.c will create the same device earlier
(without pdata) which will prevent this device to be created and at the end
will prevent omap_hdmi_audio driver to probe due to missing pdata...
+ if (IS_ERR(hdmi.audio_pdev)) {
+ DSSERR(Can't instantiate hdmi-audio\n);
+ return PTR_ERR(hdmi.audio_pdev);
+ }
+
+ return 0;
+}
+
--
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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
On 10/12/2012 06:24 PM, Tony Lindgren wrote: twl6040-codec twl6040-codec: ASoC: Failed to create Capture debugfs file Peter, can you take a look please? Patch to fix this has been already sent: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-September/055684.html The same issue has been also fixed for twl4030: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-September/055683.html -- 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: [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
On 10/08/2012 07:35 PM, Tony Lindgren wrote: - omap-dma.c and omap-pcm.c can test the arch locally as omap1 and omap2 cannot be compiled together because of conflicting compiler flags sound/soc/omap/omap-pcm.c |9 +++-- Tony: is this going to be included in 3.7? Acked-by: Peter Ujfalusi peter.ujfal...@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: [PATCH 0/9] ARM: dts/OMAP: Pinmux audio configuration for OMAP4+
On 10/06/2012 02:03 AM, Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@ti.com [121004 04:57]: Hello, u-boot recently stopped configuring 'non essential' pin mux. This change leaves the audio essential pins in non configured state which prevents the use of audio. The following series makes sure that the needed pins are configured correctly by the kernel on OMAP4 and OMAP5. Tony: can this series queued for 3.7? Let's see if that's possible to avoid mysterious bug reports of things not working. If we can't merge it, then it might be worth adding a warning that bails out early after some pin is checked or similar. With new enough u-boot the twl6040 fails to probe (mux for nirq2 and power GPIO is not configured) which leads to no audio on OMAP4/5. Adding another warning - and check - does not going to help to clarify the situation IMHO. We can still enable the CONFIG_SYS_ENABLE_PADS_ALL in u-boot and recompile it, but this is disabled as default and to be frank there is no guaranty that this is going to be available let's say next week. -- 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: Re: Re: [PATCH 06/10] ASoC: omap-abe-twl6040: Convert to platform deriver
Hi Mark, On Wednesday 14 December 2011 19:27:11 Mark Brown wrote: This seems like we need a better system for doing this, we can't go changing the machine name every time there's a kernel space change that affects a UCM file, that's going to get crazy. As of know we do not have UCM for the driver in upstream. In fact it is not recommended at the moment to use the upstream driver since we do not have the ABE/dynamic PCM upstream. There are UCM files shipped with distributions (like Linaro, ubuntu), but those UCM files will not work with the upstream kernel (due to the missing parts). It can be also confusing to have the same card name for fundamentally different sound cards. We do support the kernel shipped with distributions (with patched up ASoC), but we also need to support clean upstream version. Having to deal with mismatching UCM files does not really help here. I have not planned to change the card names in the future. Having said that I can revert back to use the names used by Linaro for example (even if the cards are different): SPD4430/Panda/PandaES If I write the UCM file it will be for the vanilla upstream sound, so we will have UCM files upstream, which does not work on the Distributions - I think this is even more confusing than having different card names initially untill we get everything upstream. -- Péter PS: Liam: what is your take on this? -- 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: Re: Re: Re: [PATCH 06/10] ASoC: omap-abe-twl6040: Convert to platform deriver
On Thursday 15 December 2011 10:17:38 Péter Ujfalusi wrote: Hi Mark, On Wednesday 14 December 2011 19:27:11 Mark Brown wrote: This seems like we need a better system for doing this, we can't go changing the machine name every time there's a kernel space change that affects a UCM file, that's going to get crazy. We can handle the different features on the card with the same name with UCM fine, so I will not change the name of the card. Will be fixed for v2. -- 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: Re: [PATCH 04/10] include: platform_data: Platform data header for OMAP4 ASoC audio
On Wednesday 14 December 2011 17:57:47 Mark Brown wrote:
On Wed, Dec 14, 2011 at 11:46:57AM +0200, Peter Ujfalusi wrote:
+enum board_type {
+ OMAP_ABE_TWL6040_SDP4430,
+ OMAP_ABE_TWL6040_PANDA,
+ OMAP_ABE_TWL6040_PANDA_ES,
+};
It seems like it might better in the long run to make this feature based
rather than enumerating the individual boards - that means that if
boards mix and match the features or add features on the side of
additional designs (eg, external amplifiers that need power control)
it's easier to scale the options.
Yes this is planed for the Dtree support, but the aim here is to get working
audio on PandaBoard as well with upstream kernel.
--
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: Re: [PATCH 06/10] ASoC: omap-abe-twl6040: Convert to platform deriver
On Wednesday 14 December 2011 18:01:00 Mark Brown wrote: On Wed, Dec 14, 2011 at 11:46:59AM +0200, Peter Ujfalusi wrote: The card's name for OMAP4 SDP4430 has been changed: SDP4430 - OMAP4-SDP4430 Why? The board appaers to be generally known as SDP4430... At the moment we do not have users using the audio on top of the upstream kernel. All distributions are using patched kernel with ABE support. In there the audio card is know as SDP4430, and we have the UCM profile for the ABE version of the OMAP4 boards there which will not work on the upstream kernel since we do not have yet the ABE in mainline kernel. My plan is to add the UCM files for the upstream version of the driver which will be updated as soon we got new features (like the ABE support). It is easier for distros also to move, when time comes to the new kernel. -- 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: Re: [PATCH v2 1/2] OMAP2+: DMA: Workaround for invalid source position
On Thursday 10 November 2011 15:02:04 Jarkko Nikula wrote:
On 11/10/2011 02:46 PM, Jarkko Nikula wrote:
On 11/07/2011 11:33 AM, Peter Ujfalusi wrote:
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid information.
We can identify this situation by checking the CDAC
register:
CDAC != 0 indicates that the DMA transfer on the channel has
been started already.
When CDAC == 0 we can not trust the CSAC value since it has
not been updated, and can contain random number.
Return the start address in case the DMA has not jet started.
Note: The CDAC register has been initialized to 0 at dma_start
time.
Signed-off-by: Peter Ujfalusipeter.ujfal...@ti.com
---
arch/arm/plat-omap/dma.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..a9983b6 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1034,6 +1034,18 @@ dma_addr_t omap_get_dma_src_pos(int lch)
if (IS_DMA_ERRATA(DMA_ERRATA_3_3) offset == 0)
offset = p-dma_read(CSAC, lch);
+ if (!cpu_is_omap15xx()) {
+ /*
+ * CDAC == 0 indicates that the DMA transfer on the channel has
+ * not been started (no data has been transferred so far).
+ * Return the programmed source start address in this case.
+ */
+ if (likely(p-dma_read(CDAC, lch)))
+ offset = p-dma_read(CSAC, lch);
+ else
+ offset = p-dma_read(CSSA, lch);
+ }
+
I think this is enough:
if (unlikely(p-dma_read(CDAC, lch) == 0))
offset = p-dma_read(CSSA, lch);
I suppose offset is ok for normal case as it is already read (twise)
above.
Or actually my proposal could have a race if CDAC changes between CSAC
read and CDAC read. In that case it's better to re-read CSAC as your
patch does after CDAC test and give to both:
Reviewed-by: Jarkko Nikula jarkko.nik...@bitmer.com
Tony, have you taken this patch? I failed to find it in the l-o tree...
--
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: Re: Re: [PATCH v3 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
On Monday 28 November 2011 11:44:05 Mark Brown wrote: Only if the user is using the same machine driver as you. If the user wants a fixed clock rate for the DMIC and sets it on init rather than resetting it every time hw_params() is called then this will break. Ah, true. Will send the update soon. -- 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: Re: [PATCH v3 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
On Sunday 27 November 2011 19:50:41 Mark Brown wrote:
On Fri, Nov 25, 2011 at 02:20:33PM +0200, Peter Ujfalusi wrote:
+ /*
+* 192KHz rate is only supported with 19.2MHz/3.84MHz clock
+* configuration. The same clock configuration allows 96KHz sampling
+* rate as well. omap_dmic_select_divider() function configures the
+* dividers for 96KHz, if the current stream is running in 192KHz we
+* can change the divider value, while respecting the machine driver
+* requested clock configuration.
+*/
+ if (params_rate(params) == 192000) {
+ if (dmic-fclk_freq == 1920 dmic-clk_div == 0x1) {
+ dmic-clk_div = 0x6;
+ } else {
+ dev_err(dmic-dev,
+ invalid clock configuration for 192KHz\n);
+ return -EINVAL;
+ }
+ }
So what happens if the user starts recording at 192kHz then goes back to
96kHz? This all feels a bit clunky and fragile.
I expect another HW param calls. The stream is stopped, and I reconfigure the
divider for 96KHz (I will not change the divider here, since the stream is
96KHz). I don't see any issue here.
The comment explains the situation, and the reasoning behind of this check,
and divider reconfiguration.
It seems like the
neatest solution here is to just record the desired DMICCLK rate when
the user sets it and then apply it here rather than doing this patching
later on.
I'm applying the divider in omap_dmic_dai_prepare callback.
--
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: Re: [PATCH v2 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
On Thursday 24 November 2011 17:10:19 Mark Brown wrote:
On Thu, Nov 24, 2011 at 03:54:46PM +0200, Peter Ujfalusi wrote:
+ /*
+* 192KHz rate is only supported with 19.2MHz/3.84MHz clock
+* configuration. Fix the dmic clock divider for 192KHz
+*/
+ if (params_rate(params) == 192000) {
+ if (dmic-fclk_freq == 1920 dmic-clk_div == 0x1) {
+ dmic-clk_div = 0x6;
+ } else {
+ dev_err(dmic-dev,
+ invalid clock configuration for 192KHz\n);
+ return -EINVAL;
+ }
+ }
That's a bit wierd, magic numbers there and it'll mean we're trashing
the user's configuration. Why not just return an error if the clock
setup is broken,
192KHz rate is supported only with one clock configuration:
19.2MHz input clock, and 3.84MHz output clock. With the same clock
configuration the 96KHz rate is also valid. The difference is that we need to
use different divider value for 96KHz (0x1) versus 192KHz (0x6).
The Machine driver configures three things: clock source, source clock speed,
and the desired output speed.
In the omap_dmic_select_divider() the driver configures the dividers, but
there it does not know if the stream is 96 or 192 KHz. Since for both the
machine provided configuration is the same I can fix up the divider in case
the stream is 192KHz, and the machine driver was asking for a clock
configuration matching with the requirements.
Basically the omap_dmic_select_divider() configures the divider for 96KHz,
here the driver does the fixup for 192KHz.
I'll update the comment to be more verbose on what is going on here.
or alternatively aren't there other invalid
configurations we should be trapping and fixing up (looking at the
divider setting code it seems unlikely that if the user doesn't
configure things we're not going to have a valid divider setup)?
So far this is the only configuration need special care.
+static int omap_dmic_set_dai_sysclk(struct snd_soc_dai *dai, int
clk_id,
+ unsigned int freq, int dir)
+{
+ struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
+
+ if (dir == SND_SOC_CLOCK_IN)
+ return omap_dmic_select_fclk(dmic, clk_id, freq);
+ else if (dir == SND_SOC_CLOCK_OUT)
+ return omap_dmic_select_divider(dmic, freq);
Might be better to specify using clk_id in case the next revision of the
IP has more clocks or something.
The fclk selection is using clk_id. I can add clk_id for the dmic_out clock.
+ dmic = kzalloc(sizeof(struct omap_dmic), GFP_KERNEL);
+ if (!dmic)
+ return -ENOMEM;
devm_ would save you having to clean stuff up later.
Yes, handy. Changed.
+static int __init snd_omap_dmic_init(void)
+{
+ return platform_driver_register(asoc_dmic_driver);
+}
+module_init(snd_omap_dmic_init);
+
+static void __exit snd_omap_dmic_exit(void)
+{
+ platform_driver_unregister(asoc_dmic_driver);
+}
+module_exit(snd_omap_dmic_exit);
module_platform_driver.
Sure.
--
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: Re: [PATCH 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
On Tuesday 22 November 2011 16:01:05 Mark Brown wrote:
On Tue, Nov 22, 2011 at 04:01:57PM +0200, Peter Ujfalusi wrote:
+ switch (params_rate(params)) {
+ case 96000:
+ case 192000:
+ break;
Why doesn't the driver need to tell the hardware what sample rate to run
at?
Because the OMAP4 DMIC can only support on 96KHz...
Will be fixed.
+ dmic_clk = clk_get(dmic-dev, dmic_fck);
+ if (IS_ERR(dmic_clk)) {
+ dev_err(dmic-dev, cant get dmic_fck\n);
+ return -ENODEV;
+ }
Why aren't we getting and holding a reference to the clock over the
entire lifetime of the driver?
We only need the reference for the dmic_fclk for reparenting which will happen
only once in most cases (or not at all, if pad_clks_ck is going to be used). I
don't think we should hold the reference for the dmic_fclk.
The clock handling is done via pm_runtime_get/put_sync().
+ /* disable clock while reparenting */
+ pm_runtime_put_sync(dmic-dev);
+ ret = clk_set_parent(dmic_clk, parent_clk);
+ pm_runtime_get_sync(dmic-dev);
Since we're only allowing reclocking while idle shouldn't the clock
already be disabled? Seems like it ought to be good for power if
nothing else...
We enable the clocks at dai_startup for the DMIC (and disable them on
dai_shutdown). We can not reparent while the clocks are enabled.
This is the reason for this part.
+static int omap_dmic_set_clkdiv(struct snd_soc_dai *dai,
+ int div_id, int div)
+{
DMIC clocking is usually fairly simple so it seems surprising that the
driver isn't able to figure this out for itself.
The clock towards the external digital mics are based on the DMIC_FCLK rate.
In case of DMIC_FCLK = 19.2MHz, 24.576MHz we can select between two dividers
which will result different clocks for the external microphones.
I would rather leave this decision to the machine driver which knows the
external components, and can pick the best divider for them.
--
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: Re: Re: [PATCH 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
On Wednesday 23 November 2011 10:58:07 Mark Brown wrote: This just seems like it's making the code needlessly complex - there's no harm in holding the reference if you don't enable/disable the clock and it makes this function much simpler. OK. We enable the clocks at dai_startup for the DMIC (and disable them on dai_shutdown). We can not reparent while the clocks are enabled. This is the reason for this part. That sounds like the enable is happening too early, then. This only enables the clock for the DMIC block, the clock for the external DMIC will start at trigger time (and stop as well). In order to access to DMIC registers we need clocks, and the clocks are enabled for the duration we have capture stream open. I would think this is acceptable. If that's what you're doing then it seems like the machine drivers should be use set_sysclk() (or perhaps even the clk API) to set up the rate they're looking for from the visible clock rather than fiddling about with magic divider values. That way they can say exactly what they want directly in terms of the result they're looking for. In OMAP4 DMIC the divider can not be chosen freely. The clock provided to the external microphones will depend on the selected DMIC_FCLK, and the divider. If I ask the machine driver to ask for specific speed for the external mic, the writer of the machine driver anyways have to look up the table from the TRM for the possible frequencies. So instead of providing magic divider it has to provide magic speed. I can do that if you prefer that way, but it just going to 'complicate' the driver a bit (well not that much, we just will have different way of looking up the register value for the divider, and it will be done in omap_dmic_set_dai_sysclk instead of omap_dmic_set_clkdiv). -- 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: Re: Re: Re: [PATCH 2/5] ASoC: OMAP4: omap-dmic: Initial support for OMAP DMIC
On Wednesday 23 November 2011 14:30:50 Mark Brown wrote: Meh, I guess. It's hard to love code-wise. So you would prefer me to enable the OMAP DMIC's clocks at pcm_trigger:start time, and disable them on pcm_trigger:stop? I have seen cases when the driver did not received the pcm_trigger:stop prior to pcm_close call, so in that case a safety check in dai_shutdown is needed to be sure the dmic clocks are really disabled. I would still prefer to keep the dmic clocks enabled for the duration the stream is open. On the other hand if I had it in pcm_trigger, I don't need to play with the clocks when reparenting... If that's what you're doing then it seems like the machine drivers should be use set_sysclk() (or perhaps even the clk API) to set up the rate they're looking for from the visible clock rather than fiddling about with magic divider values. That way they can say exactly what they want directly in terms of the result they're looking for. In OMAP4 DMIC the divider can not be chosen freely. The clock provided to the external microphones will depend on the selected DMIC_FCLK, and the divider. If I ask the machine driver to ask for specific speed for the external mic, the writer of the machine driver anyways have to look up the table from the TRM for the possible frequencies. So instead of providing magic divider it has to provide magic speed. Sure, but on the other hand it means that someone reading the machine driver can tell what's going on without going back to the magic table either. Having the rates in the code makes the code more legible and means that people can at least refer to the DMIC driver for a list of supported rates rather than having to find the TRM. I'd also guess that it's much more likely that people will remember clock rates they can set than divider tables but perhaps that's just me. Sure, I will change the driver accordingly. -- 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: Re: [PATCH 1/2] OMAP2+: DMA: Workaround for invalid source position
On Thursday 03 November 2011 14:27:56 Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [111031 06:46]:
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid information.
We can identify this situation by checking the CDAC
register:
CDAC != 0 indicates that the DMA transfer on the channel has
been started already.
When CDAC == 0 we can not trust the CSAC value since it has
not been updated, and can contain random number.
Return the start address in case the DMA has not jet started.
Note: The CDAC register has been initialized to 0 at dma_start
time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/dma.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..38b0d44 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1024,12 +1024,23 @@ EXPORT_SYMBOL(omap_set_dma_callback);
*/
dma_addr_t omap_get_dma_src_pos(int lch)
{
+ u32 cdac;
dma_addr_t offset = 0;
if (cpu_is_omap15xx())
offset = p-dma_read(CPC, lch);
- else
- offset = p-dma_read(CSAC, lch);
+ else {
+ /*
+* CDAC == 0 indicates that the DMA transfer on the channel has
+* not been started (no data has been transferred so far).
+* Return the programmed source start address in this case.
+*/
+ cdac = p-dma_read(CDAC, lch);
+ if (likely(cdac))
+ offset = p-dma_read(CSAC, lch);
+ else
+ offset = p-dma_read(CSSA, lch);
+ }
if (IS_DMA_ERRATA(DMA_ERRATA_3_3) offset == 0)
offset = p-dma_read(CSAC, lch);
Should these tests be done only after the errata re-read for both
src and dst patches? Otherwise the errata will not be handled?
Yes that might be a good idea.
I was trying to locate the original errata description for DMA_ERRATA_3_3, but
it does not exist, or at least I can not find it. This only been mentioned in
the kernel's comment.
I'm not sure when this DMA_ERRATA_3_3 would have been in force. My guess would
be that if someone wants to read the src/dst position right after the channel
is disabled, but what would we expect it to return when the channel has been
disabled?
I mean what is the reasonable src/dst for a disabled channel? 0 is as good as
any other number, probably the programmed start of the DMA transfer would be
my best bet.
I think the errata description for DMA_ERRATA_3_3 is not correct, and it is in
fact to handle the case I'm also handling: Before the first DMA request the
CDAC is 0 (since we configured it to be), the CSAC contains _something_ (most
of the time 0, but can be random number).
In some situation re-reading the src/dst position will give enough time to
receive the first DMA request, which will update CDAC/CSAC registers.
What do you think?
--
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: OMAP: TWL4030: Sound broken in 3.1
On Friday 04 November 2011 15:18:05 Joe Woodward wrote: In 3.1 sound support is broken for any boards using a TWL4030-based CODEC. The Kconfig option for the TWL4030 CODEC used to be TWL4030_CODEC, and in 3.1 this has been changed to MFD_TWL4030_AUDIO. I believe this has caused a problem in drives/mfd/twl-core.c:112 as the define for the twl_has_codec() macro still tests for CONFIG_TWL4030_CODEC. Hence the macro always returns false and during boot I get: [2.417999] ALSA device list: [2.421142] No soundcards found. Is this likely to be the problem? See Jarkko's patch: https://lkml.org/lkml/2011/10/19/125 -- 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: [alsa-devel] [PATCH 0/3] ASoC: tpa6130a2: model handling cleanup
Hello Mark, Tony, On Tuesday 30 August 2011 13:39:51 Ujfalusi, Peter wrote: Hello, Small cleanup for the tpa6130a2 driver for model handling: Remove the model_id from platform_data, and use the device name/device_data to distinguish between the supported models of TPA. Would you have time to take a look at this series (it got the Tested-by from Jarkko)? Thank you, 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: [PATCH] ASoC/MFD: twl4030: Fix dependencies for audio codec
On Monday 05 September 2011 11:26:33 Thomas Weber wrote: The codec for Devkit8000 (TWL4030) was not detected except when build with CONFIG_SND_SOC_ALL_CODECS. twl-core.c still uses the CONFIG_TWL4030_CODEC for twl_has_codec(). acked-by: Peter Ujfalusi peter.ujfal...@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: Re: Re: [alsa-devel] [PATCH 0/4] ASoC: OMAP4: McPDM: Fix legacy support
On Friday 19 August 2011 15:04:20 Tony Lindgren wrote: It seems OK to me. Thanks! But for the -rc cycle it has potential for fixes for features that never worked flame bait. If you guys are OK to deal with that then go ahead. Hrm, I have not thought about this. Not sure, if we want to go there... -- 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: ALSA SoC TWL4030 driver
On Tuesday 16 August 2011 15:33:09 Maximilian Schwerin wrote:
Hi,
I'm currently working on a beagle board clone.
I've got some problems getting the micbias1 output on the TPS65950 to work.
I can record audio coming from a line out or if I connect micbias1 to an
extern 1.8V supply.
/sys/devices/platform/soc-audio/TWL4030/dapm_widget shows Mic Bias 1 to be
off at all times. Is there something I have to do to enable this other than
to start recording? Or could this be a bug in the driver? Does anyone have
experience with the mic input of the TPS65950?
In your machine driver you need to connect the corresponding mic bias, like it
is done in for example for zoom2:
/* Headset Mic: HSMIC with bias */
{HSMIC, NULL, Headset Mic Bias},
{Headset Mic Bias, NULL, Headset Mic},
Note: Beagle only have support for line-in, does your board have additional
inputs jack (Headset?)
--
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: Re: [alsa-devel] [PATCH 0/4] ASoC: OMAP4: McPDM: Fix legacy support
Hi Tony, On Tuesday 09 August 2011 09:27:17 Ujfalusi, Peter wrote: Hi Tony, On Tuesday 02 August 2011 13:34:13 Ujfalusi, Peter wrote: Hello, The OMAP4 McPDM driver in upstream has been broken for some time... This series fixes that, and enables basic audio playback/capture over the mcpdm interface. Would you have time to look at this series? Specially patch 1 (maybe 2 as well). We are planning to send this series through audio for 3.1. Do you have time to look at this series. Currently the mcpdm (omap4 audio) is broken in upstream without this series, and I'd like to have it fixed in time for 3.1. Two patch in this series has been taken from the OMAP4/ASoC: New McPDM driver series (patch 1, and 2) [1]. Since I was on holiday, I did not had time to rewrite the driver rewrite patch, but I feel that fixing the basic audio support for OMAP4 is needed. The aim here is to have working audio in upstream kernel for 3.1, and have the new McPDM driver stack up for the 3.2 release. Thank you, 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: [alsa-devel] [PATCH 0/4] ASoC: OMAP4: McPDM: Fix legacy support
Hi Tony, On Tuesday 02 August 2011 13:34:13 Ujfalusi, Peter wrote: Hello, The OMAP4 McPDM driver in upstream has been broken for some time... This series fixes that, and enables basic audio playback/capture over the mcpdm interface. Would you have time to look at this series? Specially patch 1 (maybe 2 as well). We are planning to send this series through audio for 3.1. Two patch in this series has been taken from the OMAP4/ASoC: New McPDM driver series (patch 1, and 2) [1]. Since I was on holiday, I did not had time to rewrite the driver rewrite patch, but I feel that fixing the basic audio support for OMAP4 is needed. The aim here is to have working audio in upstream kernel for 3.1, and have the new McPDM driver stack up for the 3.2 release. [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2011-July/041687.html Br, Peter --- Peter Ujfalusi (4): OMAP: McPDM: Convert McPDM device to omap_device OMAP4: hwmod: enable mcpdm hwmod device. ASoC: omap-mcpdm: Fix threshold and dma configuration ASoC: OMAP4: McPDM: Convert to hwmod/omap_device arch/arm/mach-omap2/devices.c | 33 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/devices.c | 36 -- sound/soc/omap/mcpdm.c | 38 +++ sound/soc/omap/mcpdm.h | 1 - sound/soc/omap/omap-mcpdm.c| 19 + sound/soc/omap/sdp4430.c |2 +- 7 files changed, 69 insertions(+), 62 deletions(-) Thanks, 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: OMAP3 kernels fail to build
Hi Russel, On Monday 08 August 2011 13:00:56 Russell King - ARM Linux wrote: With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this: arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init' arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit' arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power' arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk' arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend' This is probably from twl-common.c, which doesn't really look very common to me (looks like some is specific to OMAP3 and the rest is OMAP4 specific.) As this is always built for all OMAP2+, this will also break OMAP2 as well. Why it's even built on OMAP2, I've no idea. I'm sure if you have it other way around (OMAP4=y, OMAP3=n) will fail as well, but differently... I think the OMAP3 specific bits should be separate from the OMAP4 specific bits, which should be separate from the small amount of common stuff. Is it acceptable if I use #if defined(CONFIG_ARCH_OMAP3), and #if defined(CONFIG_ARCH_OMAP4) to protect the OMAP3 and OMAP4 related code in the twl-common.c? -- 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: Re: Build failure: bisected: v3.1-rc1 with config ARCH_OMAP !ARCH_OMAP4 fails with linker error
Hi Tony, Paul, On Tuesday 09 August 2011 15:14:53 Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [110808 13:31]: Hi On Mon, 8 Aug 2011, Daniel Morsing wrote: Building the v3.1-rc1 kernel with ARCH_OMAP !ARCH_OMAP4 support fails on linking with the following error ... LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o:(.data+0xf7d8): undefined reference to `omap4430_phy_init' arch/arm/mach-omap2/built-in.o:(.data+0xf7dc): undefined reference to `omap4430_phy_exit' arch/arm/mach-omap2/built-in.o:(.data+0xf7e0): undefined reference to `omap4430_phy_power' arch/arm/mach-omap2/built-in.o:(.data+0xf7e4): undefined reference to `omap4430_phy_set_clk' arch/arm/mach-omap2/built-in.o:(.data+0xf7e8): undefined reference to `omap4430_phy_suspend' I've bisected the first bad commit to OMAP4: Move common twl6030 configuration to twl-common (commit-id b22f954bae35be115a10c6426dc070f7d652b32e). The problem seems to be unconditionally taking a function pointer to an omap4430 specific function in arch/arm/mach-omap2/twl-common.c. The definition for omap4430_phy_init and friends is in arch/arm/mach-omap2/omap_phy_internal.c, which is only compiled when building with support for one of the omap4430 boards. Thanks for the bisect; this should be fixed by https://patchwork.kernel.org/patch/963462/ Hmm, there are also these when CONFIG_ARCH_OMAP4 is not selected: arch/arm/mach-omap2/built-in.o: In function `_enable_module': arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to `omap4_cminst_module_enable' arch/arm/mach-omap2/built-in.o: In function `_disable_module': arch/arm/mach-omap2/omap_hwmod.c:726: undefined reference to `omap4_cminst_module_disable' arch/arm/mach-omap2/built-in.o: In function `_wait_target_disable': arch/arm/mach-omap2/omap_hwmod.c:1179: undefined reference to `omap4_cminst_wait_module_idle' distcc[27594] ERROR: compile (null) on localhost failed make: *** [.tmp_vmlinux1] Error 1 Care to take a look? I just sent a patch fixing this: http://marc.info/?l=linux-omapm=131289342114258w=2 -- 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: [alsa-devel] [PATCH 4/4] ASoC: OMAP4: McPDM: Convert to hwmod/omap_device
On Tuesday 02 August 2011 13:34:17 Ujfalusi, Peter wrote: In order to probe, and operate correctly, the OMAP McPDM driver needs to be converted to use hwmod. The device name has been changed to probe the driver. Replace the clk_* with pm_runtime_* calls to manage the clocks correctly. Missing request_mem_region/release_mem_region added. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- sound/soc/omap/mcpdm.c | 38 +- sound/soc/omap/mcpdm.h |1 - sound/soc/omap/omap-mcpdm.c |2 +- sound/soc/omap/sdp4430.c|2 +- 4 files changed, 23 insertions(+), 20 deletions(-) diff --git a/sound/soc/omap/mcpdm.c b/sound/soc/omap/mcpdm.c index 928f037..d29cc98 100644 --- a/sound/soc/omap/mcpdm.c +++ b/sound/soc/omap/mcpdm.c @@ -28,7 +28,7 @@ #include linux/slab.h #include linux/interrupt.h #include linux/err.h -#include linux/clk.h +#include linux/pm_runtime.h #include linux/delay.h #include linux/io.h #include linux/irq.h @@ -322,11 +322,11 @@ static irqreturn_t omap_mcpdm_irq_handler(int irq, void *dev_id) return IRQ_HANDLED; } -int omap_mcpdm_request(void) + int omap_mcpdm_request(void) Just noticed this one. Going to resend, or Liam can you fix this up when you take the patches? -- 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: [alsa-devel] [PATCH 1/3] mfd: twl6040: Add initial support
Oops... On Tuesday 02 August 2011 13:28:41 Ujfalusi, Peter wrote: From: Misael Lopez Cruz misael.lo...@ti.com TWL6040 IC provides analog high-end audio codec functions for handset applications. It contains several audio analog inputs and outputs as well as vibrator support. It's connected to the host processor via PDM interface for audio data communication. The audio modules are controlled by internal registers that can be accessed by I2C and PDM interface. TWL6040 MFD will be registered as a child of TWL-CORE, and will have two children of its own: twl6040-codec and twl6040-vibra. This driver is based on TWL4030 and WM8350 MFD drivers. I have sent the patches from wrong directory :( Please disregard this series, this has been already merged... Sorry! -- 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: Re: [PATCH 2/4] Fixes for input: Add initial support for TWL6040 vibrator
Hi Felipe,
On Tuesday 02 August 2011 14:33:09 Balbi, Felipe wrote:
Hi,
On Tue, Aug 02, 2011 at 02:28:42PM +0300, Peter Ujfalusi wrote:
@@ -145,7 +143,7 @@ static int vibra_play(struct input_dev *input, void
*data,
ret = queue_work(info-workqueue, info-play_work);
if (!ret) {
- dev_err(input-dev, work is already on queue\n);
+ dev_info(input-dev, work is already on queue\n);
why ???
Please do not waste your valuable time on this series.
It was an error in my side to send it (just came back form vacation...).
I have somehow ended up in a wrong directory when I typed git send-email, and
sent the wrong set of patches.
Not these, but the fixed/cleaned ones are already merged upstream.
Sorry for the inconvenience I have caused.
--
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: Re: Re: [PATCH 1/3] ASoC: omap-mcpdm: Replace legacy driver
On Saturday 09 July 2011 03:08:10 Mark Brown wrote: I've got a few ideas but nothing comprehensive right now; the main thing I can think we're missing at the minute is more fine grained hooks around stream start in order to allow things to clock off the audio stream. Equally well none of the systems I've had to deal with have had a particularly pressing problem here. Yeah, this is the first system if this kind I've seen as well. Anyway, we have these constraints, and these might come back in other designs in the future. We will be looking for better/cleaner way to handle this. If the machine driver controls the system integration (as we're doing for everything else) it's at least clear what's going on for this particular system. My main concern here is making the code actually say what's going on. Fair enough. Could we split the rewrite out from the delay thing so we can review it separately? This'd also be good from the point of view of documentation of what's going on as the changelogs would provide a bit more details. Just to avoid confusion (in my part): if I split this patch to one big + several small incremental patches, which eventually lead to the current situation is what you were asking for? With the patches I can document the reasoning behind the non standard workarounds. Probably if we see them spread out, we might be able to find better ways for them... -- 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: Re: [PATCH 1/3] ASoC: omap-mcpdm: Replace legacy driver
On Friday 08 July 2011 16:28:05 Mark Brown wrote: It's not that simple in this situation. We also have a PM dependency on the CODEC here too, it supplies our interface clock via the DAI so we have to be very careful how we interact with the ABE and CODEC. The critical thing here is the pop reduction and a subsequent ABE patch will also introduce some hard timing constraints here too. This definitely feels like it needs sorting in a better way than just inserting random delays into drivers I agree, there should be a better way to handle this. the clocking dependencies are far from unique, for example, and would normally be managed by the machine drivers with the current infrastructure. Sort of yes, but as soon as we have more devices, we will need either ways in the core, or some common file to handle the clocking, startup, and other dependencies between McPDM and the twl6040 - I'm completely ignoring the ABE here. BTW: what infrastructure you are suggesting? Right now it's all sounding far too fragile due to the lack of any explicit indication of what's going on and the fact that things are going to be spread over a bunch of different drivers. Agreed, but... if we handle the McPDM stop start from the outside, will it help? I mean we need to keep on eye what the twl6040 is doing, and do things accordingly within the McPDM. If we just insert random delays into the drivers the chances of anyone understanding what the code is supposed to be doing in the future seem low which isn't going to be nice when people do different designs. Again: agreed. Unfortunately this cleanup work has to wait, since at least I'm going for a holiday. Another, not directly related thing is that with this driver in place at least one can play audio on OMAP4 with upstream kernel (through McPDM, and without ABE). This area is still work in progress, but I prefer to start from something, which shows some sign of life. -- 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
[GIT PULL] TWL6040 MFD and followups
Hello Tony, As it has been discussed I'm sending this pull request, which includes the following series (all patch acked-by the corresponding maintainer): 1. v6 of MFD/ASoC/Input: TWL4030/TWL60X0 changes (18 patch) 2. v3 of MFD/input/ASoC: twl6040: irq registration changes (5 patch) 3. v1 of ASoC/MFD: twl6040: PLL handling changes (6 patch) 4. ASoC: twl6040: Add back support for legacy mode (single patch) The first series starts with a cleanup in the mach-omap2 directory (twl-common.c file created), and that is the reason we agreed that you are going to take this pull request. The rest of the changes are well contained, and should not cause merge conflict for 3.1. We have not sent patches for these components, so the changes to these are coming from one source. As you have requested I have created the series on top of your devel-cleanup branch. Best regards, Péter --- The following changes since commit 48cb1258e8b0f8c81cfb699b42326c5b2147b3f8: Merge branch 'for_3.1/pm-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into devel-cleanup (2011-06-29 04:45:16 -0700) are available in the git repository at: git://gitorious.org/omap-audio/linux-audio.git peter/topic/for-tony Axel Castaneda Gonzalez (1): ASoC: twl6040: Configure ramp step based on platform Liam Girdwood (3): ASoC: twl6040: add all ABE DAIs ASoC: twl6040: Support other sample rates in constraints. ASoC: twl6040: set default constraints. Misael Lopez Cruz (5): mfd: twl6040: Add initial support ASoC: twl6040: Convert into TWL6040 MFD child input: Add initial support for TWL6040 vibrator ASoC: twl6040: Remove pll and headset mode dependency OMAP4: SDP4430: Add twl6040 codec platform support Peter Ujfalusi (21): OMAP: New twl-common for common TWL configuration OMAP4: Move common twl6030 configuration to twl-common OMAP3: Move common twl configuration to twl-common OMAP3: Move common regulator configuration to twl-common MFD: twl4030-codec: Rename internals from codec to audio MFD: twl4030-codec - twl4030-audio: Rename the driver MFD: twl4030-audio: Rename platform data MFD: twl6040: Change platform data for soc codec driver OMAP4: SDP4430: Add twl6040 vibrator platform support MFD: twl6040: Use resource to provide irq number for slaves input: twl6040-vibra: Do not use wrapper for irq request ASoC: twl6040: Do not use wrapper for irq request MFD: twl6040: Demand valid interrupt configuration MFD: twl6040: Remove wrapper for threaded irq request ASoC: twl6040: Use neutral name for power mode text/enum ASoC: twl6040: Move PLL selection to codec driver ASoC: twl6040: Simplify sample rate constraint handling ASoC: twl6040: Configure PLL only once MFD: twl6040: Remove enum for PLL tracking ASoC: twl6040: No need to convert the PLL ID ASoC: twl6040: Add back support for legacy mode arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/board-3430sdp.c| 89 +--- arch/arm/mach-omap2/board-4430sdp.c| 185 ++ arch/arm/mach-omap2/board-cm-t35.c | 51 +-- arch/arm/mach-omap2/board-devkit8000.c | 38 +- arch/arm/mach-omap2/board-igep0020.c | 44 +- arch/arm/mach-omap2/board-ldp.c| 15 +- arch/arm/mach-omap2/board-omap3beagle.c| 62 +-- arch/arm/mach-omap2/board-omap3evm.c | 70 +-- arch/arm/mach-omap2/board-omap3pandora.c | 62 +-- arch/arm/mach-omap2/board-omap3stalker.c | 72 +-- arch/arm/mach-omap2/board-omap3touchbook.c | 61 +-- arch/arm/mach-omap2/board-omap4panda.c | 146 + arch/arm/mach-omap2/board-overo.c | 61 +-- arch/arm/mach-omap2/board-rm680.c |8 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 46 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 89 +-- arch/arm/mach-omap2/common-board-devices.c | 21 - arch/arm/mach-omap2/common-board-devices.h | 26 +- arch/arm/mach-omap2/twl-common.c | 304 arch/arm/mach-omap2/twl-common.h | 59 ++ arch/arm/plat-omap/include/plat/irqs.h | 12 +- drivers/input/misc/Kconfig | 13 +- drivers/input/misc/Makefile|1 + drivers/input/misc/twl4030-vibra.c | 12 +- drivers/input/misc/twl6040-vibra.c | 423 +++ drivers/mfd/Kconfig|8 +- drivers/mfd/Makefile |3 +- drivers/mfd/twl-core.c | 13 +- drivers/mfd/twl4030-audio.c| 277 drivers/mfd/twl4030-codec.c| 277 drivers/mfd/twl6040-core.c
Re: Re: [PATCH 1/3] ASoC: omap-mcpdm: Replace legacy driver
On Thursday 07 July 2011 18:53:29 Mark Brown wrote: Sounds like runtime PM ought to be able to handle this, though? If you need to sync with the ABE can the ABE take PM references to the DAIs it's talking to? It is not (just?) the ABE, but rather the twl6040 codec, which needs this deferred stopping of the PDM interface. AFAIK. I guess the ABE will be happier if everything it's talking to runs for longer than it does. Or the DAI could switch into autosuspend mode when it goes idle to do the delay. -- 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: Re: [GIT PULL] TWL6040 MFD and followups
On Thursday 07 July 2011 20:29:47 Tony Lindgren wrote: Thanks. Can you please add one more branch for cleanup only for me to pull at your commit b252b0efb605b92a2f5d118e294d088d89cfd286 (OMAP3: Move common regulator configuration to twl-common)? Do you want a separate pull request for it? The branch name, which only have the cleanup (ends with b252b0efb605b92a2f5d118e294d088d89cfd286): peter/topic/for-tony_mach-cleanup That way I can first pull that into cleanup and send that to Arnd. Then we can do a separate twl-asoc branch so the cleanup stays separate from new code. Sound like a plan. -- 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: Re: Re: [PATCH v6 08/18] mfd: twl6040: Add initial support
Hi Samuel, On Monday 04 July 2011 19:39:35 Samuel Ortiz wrote: That is fine with me, yes. That's why I ACK the MFD patches for Tony to take them. I have changed the series for Tony in my branch for the following comments: wl6040_is_powered, twl6040_get_rev removal, since these are really small changes, if you want to see it before Tony pulls it, I can send the selected patches (few lines has been changed). Thanks in advance for the follow up patches. For the twl6040_*_irq changes, I sent the series, since I ended up with a bigger change than I would have expected. Regards, 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: Re: [PATCH v6 08/18] mfd: twl6040: Add initial support
Hi Felipe, Samuel, On Monday 04 July 2011 14:53:30 Balbi, Felipe wrote: + ret = twl6040_request_irq(twl6040, TWL6040_IRQ_READY, + twl6040_naudint_handler, 0, + twl6040_irq_ready, twl6040); why don't you use the normal request_threaded_irq() ?? This is a bit of obfuscation IMO. I have left this 'macro' in since it is also used within the twl6040-vibra, and twl6040 ASoC codec driver to request the irq for them. But if you think it is better to replace the twl6040_request_irq with direct request_threaded_irq in those drivers as well, I'll do that. -- 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: Re: [PATCH v6 08/18] mfd: twl6040: Add initial support
Hi Samuel,
On Monday 04 July 2011 13:48:44 Samuel Ortiz wrote:
Hi Peter,
On Tue, Jun 21, 2011 at 04:39:06PM +0300, Peter Ujfalusi wrote:
+int twl6040_is_powered(struct twl6040 *twl6040)
+{
+ return twl6040-power_count;
+}
+EXPORT_SYMBOL(twl6040_is_powered);
Do we really need to export this one ?
No, we don't.
At the end we do not need this function at all either.
I'm going to remove it.
+static inline int twl6040_get_rev(struct twl6040 *twl6040)
+{
+ return twl6040-rev;
+}
No need for this either, I'll remove it.
+
+static inline int twl6040_request_irq(struct twl6040 *twl6040, int irq,
+ irq_handler_t handler,
+ unsigned long irqflags,
+ const char *name,
+ void *data)
+{
+ if (!twl6040-irq_base)
+ return -EINVAL;
+
+ return request_threaded_irq(twl6040-irq_base + irq, NULL, handler,
+ irqflags, name, data);
+}
+
+static inline void twl6040_free_irq(struct twl6040 *twl6040, int irq,
+ void *data)
+{
+ if (!twl6040-irq_base)
+ return;
+
+ free_irq(twl6040-irq_base + irq, data);
+}
I don't see the value of those 3 inline functions. Removing them would make
the code actually more understandable (especially for the 2nd one).
The twl6040_request_irq is also used by the ASoC codec driver, and the vibra
driver, but if you think it is better to replace those as well, I will do it
right away.
--
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: Re: [PATCH v6 08/18] mfd: twl6040: Add initial support
Hi Samuel, On Monday 04 July 2011 13:48:44 Samuel Ortiz wrote: I don't see the value of those 3 inline functions. Removing them would make the code actually more understandable (especially for the 2nd one). Is it OK for you if I fix these as a follow-up series, so I do not need to rewrite this series, and resend it? -- 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: Re: [alsa-devel] [PATCH v6 00/18] MFD/ASoC/Input: TWL4030/TWL60X0 changes
Hi Samuel, Would you be able to take a look at this series? I already have the rebased version on top of linux-omap/devel-cleanup branch as Tony requested, and I'm now waiting for your comments. Thank you, Péter On Monday 27 June 2011 11:43:57 Ujfalusi, Peter wrote: Hi Tony, Samuel, Would you have time to take a look at this series? Thanks, Péter On Tuesday 21 June 2011 15:38:58 Ujfalusi, Peter wrote: Hello, Changes since v5: - Use alloc_workqueue in the twl6040-vibra driver (comment from Tejun Heo) - Allow user to change the headset power mode, but if the change is not allowed by the use case the change is not written to the HW (comment from Mark Brown) Mark: I have added your acks for the patches, except for patch 15, where you requested a change. Intro message from the v5 series: The series will do five major things, and they are in one series, because they pretty much depending on each other, so it is easier to handle them together. 1. Move the common pmic related configurations out from the board files. New twl-common.c/h file has been created for this purpose. OMAP3 board files received two patches (pdata, and regualtor changes), OMAP4 board files has been changed with one patch. 2. Rename the twl4030-codec MFD driver to twl4030-audio Since the ASoC multicomponent introduction (2.6.37) the twl4030-codec MFD dirver had been using twl4030-audio to register (twl4030-codec is the ASoC codec driver). The documentation refers to this part of twl as audio block, so it is better to rename the driver as well to avoid confusion. 3. Introduction of MFD driver for twl6040. The TWL6040 audio IC has codec and vibra functionality. Convert the existing ASoC codec driver to use the new MFD driver's interface. 4. Vibrator driver for TWL6040 (Input/ForceFeedback driver) The driver itself, and support for the vibrators in SDP4430 board. 5. Updates for twl6040 ASoC codec driver HS ramp configuration, new ABE dais, updated sample rate constraints, SDP4430 configuration. Regards, Peter --- Axel Castaneda Gonzalez (1): ASoC: twl6040: Configure ramp step based on platform Liam Girdwood (3): ASoC: twl6040: add all ABE DAIs ASoC: twl6040: Support other sample rates in constraints. ASoC: twl6040: set default constraints. Misael Lopez Cruz (5): mfd: twl6040: Add initial support ASoC: twl6040: Convert into TWL6040 MFD child input: Add initial support for TWL6040 vibrator ASoC: twl6040: Remove pll and headset mode dependency OMAP4: SDP4430: Add twl6040 codec platform support Peter Ujfalusi (9): OMAP: New twl-common for common TWL configuration OMAP4: Move common twl6030 configuration to twl-common OMAP3: Move common twl configuration to twl-common OMAP3: Move common regulator configuration to twl-common MFD: twl4030-codec: Rename internals from codec to audio MFD: twl4030-codec - twl4030-audio: Rename the driver MFD: twl4030-audio: Rename platform data MFD: twl6040: Change platform data for soc codec driver OMAP4: SDP4430: Add twl6040 vibrator platform support arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/board-3430sdp.c| 89 +--- arch/arm/mach-omap2/board-4430sdp.c| 187 ++ arch/arm/mach-omap2/board-cm-t35.c | 48 +-- arch/arm/mach-omap2/board-devkit8000.c | 37 +-- arch/arm/mach-omap2/board-igep0020.c | 44 +-- arch/arm/mach-omap2/board-ldp.c| 15 +- arch/arm/mach-omap2/board-omap3beagle.c| 60 +-- arch/arm/mach-omap2/board-omap3evm.c | 67 +-- arch/arm/mach-omap2/board-omap3pandora.c | 59 +-- arch/arm/mach-omap2/board-omap3stalker.c | 70 +-- arch/arm/mach-omap2/board-omap3touchbook.c | 57 +-- arch/arm/mach-omap2/board-omap4panda.c | 149 +- arch/arm/mach-omap2/board-overo.c | 59 +-- arch/arm/mach-omap2/board-rm680.c |8 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 44 +-- arch/arm/mach-omap2/board-zoom-peripherals.c | 88 +--- arch/arm/mach-omap2/common-board-devices.c | 21 - arch/arm/mach-omap2/common-board-devices.h | 26 +- arch/arm/mach-omap2/twl-common.c | 304 ++ arch/arm/mach-omap2/twl-common.h | 59 ++ arch/arm/plat-omap/include/plat/irqs.h | 12 +- drivers/input/misc/Kconfig | 13 +- drivers/input/misc/Makefile|1 + drivers/input/misc/twl4030-vibra.c | 12 +- drivers/input/misc/twl6040-vibra.c | 416 + drivers/mfd/Kconfig|8 +- drivers/mfd/Makefile
Re: Re: Re: [alsa-devel] [PATCH v6 00/18] MFD/ASoC/Input: TWL4030/TWL60X0 changes
Hi Samuel, On Thursday 30 June 2011 10:04:43 Samuel Ortiz wrote: I will do that very soon, no worries. Thank you very much, I'm going to have another series on top of this one coming, and want to make sure that I'm in the right track. Thanks, 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: Re: Re: [PATCH v6 00/18] MFD/ASoC/Input: TWL4030/TWL60X0 changes
Hi Tony, On Tuesday 28 June 2011 08:17:21 Tony Lindgren wrote: OK. Assuming Samuel is fine with the patches, care to put together a branch against devel-cleanup for me to pull? While waiting for Samuel, I can start preparing the branch for you, since the bulk of the conflicts are in mach-omap2, should not affect the MFD parts. Can I add your ack to the mach-omap2 parts, or are you prefer to handle this yourself? -- 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: [PATCH v6 00/18] MFD/ASoC/Input: TWL4030/TWL60X0 changes
Hi Tony, Samuel, Would you have time to take a look at this series? Thanks, Péter On Tuesday 21 June 2011 15:38:58 Ujfalusi, Peter wrote: Hello, Changes since v5: - Use alloc_workqueue in the twl6040-vibra driver (comment from Tejun Heo) - Allow user to change the headset power mode, but if the change is not allowed by the use case the change is not written to the HW (comment from Mark Brown) Mark: I have added your acks for the patches, except for patch 15, where you requested a change. Intro message from the v5 series: The series will do five major things, and they are in one series, because they pretty much depending on each other, so it is easier to handle them together. 1. Move the common pmic related configurations out from the board files. New twl-common.c/h file has been created for this purpose. OMAP3 board files received two patches (pdata, and regualtor changes), OMAP4 board files has been changed with one patch. 2. Rename the twl4030-codec MFD driver to twl4030-audio Since the ASoC multicomponent introduction (2.6.37) the twl4030-codec MFD dirver had been using twl4030-audio to register (twl4030-codec is the ASoC codec driver). The documentation refers to this part of twl as audio block, so it is better to rename the driver as well to avoid confusion. 3. Introduction of MFD driver for twl6040. The TWL6040 audio IC has codec and vibra functionality. Convert the existing ASoC codec driver to use the new MFD driver's interface. 4. Vibrator driver for TWL6040 (Input/ForceFeedback driver) The driver itself, and support for the vibrators in SDP4430 board. 5. Updates for twl6040 ASoC codec driver HS ramp configuration, new ABE dais, updated sample rate constraints, SDP4430 configuration. Regards, Peter --- Axel Castaneda Gonzalez (1): ASoC: twl6040: Configure ramp step based on platform Liam Girdwood (3): ASoC: twl6040: add all ABE DAIs ASoC: twl6040: Support other sample rates in constraints. ASoC: twl6040: set default constraints. Misael Lopez Cruz (5): mfd: twl6040: Add initial support ASoC: twl6040: Convert into TWL6040 MFD child input: Add initial support for TWL6040 vibrator ASoC: twl6040: Remove pll and headset mode dependency OMAP4: SDP4430: Add twl6040 codec platform support Peter Ujfalusi (9): OMAP: New twl-common for common TWL configuration OMAP4: Move common twl6030 configuration to twl-common OMAP3: Move common twl configuration to twl-common OMAP3: Move common regulator configuration to twl-common MFD: twl4030-codec: Rename internals from codec to audio MFD: twl4030-codec - twl4030-audio: Rename the driver MFD: twl4030-audio: Rename platform data MFD: twl6040: Change platform data for soc codec driver OMAP4: SDP4430: Add twl6040 vibrator platform support arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/board-3430sdp.c| 89 +--- arch/arm/mach-omap2/board-4430sdp.c| 187 ++ arch/arm/mach-omap2/board-cm-t35.c | 48 +-- arch/arm/mach-omap2/board-devkit8000.c | 37 +-- arch/arm/mach-omap2/board-igep0020.c | 44 +-- arch/arm/mach-omap2/board-ldp.c| 15 +- arch/arm/mach-omap2/board-omap3beagle.c| 60 +-- arch/arm/mach-omap2/board-omap3evm.c | 67 +-- arch/arm/mach-omap2/board-omap3pandora.c | 59 +-- arch/arm/mach-omap2/board-omap3stalker.c | 70 +-- arch/arm/mach-omap2/board-omap3touchbook.c | 57 +-- arch/arm/mach-omap2/board-omap4panda.c | 149 +- arch/arm/mach-omap2/board-overo.c | 59 +-- arch/arm/mach-omap2/board-rm680.c |8 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 44 +-- arch/arm/mach-omap2/board-zoom-peripherals.c | 88 +--- arch/arm/mach-omap2/common-board-devices.c | 21 - arch/arm/mach-omap2/common-board-devices.h | 26 +- arch/arm/mach-omap2/twl-common.c | 304 ++ arch/arm/mach-omap2/twl-common.h | 59 ++ arch/arm/plat-omap/include/plat/irqs.h | 12 +- drivers/input/misc/Kconfig | 13 +- drivers/input/misc/Makefile|1 + drivers/input/misc/twl4030-vibra.c | 12 +- drivers/input/misc/twl6040-vibra.c | 416 + drivers/mfd/Kconfig|8 +- drivers/mfd/Makefile |3 +- drivers/mfd/twl-core.c | 13 +- drivers/mfd/twl4030-audio.c| 277 + drivers/mfd/twl4030-codec.c| 277 - drivers/mfd/twl6040-core.c | 601 +++ drivers/mfd/twl6040-irq.c | 205 +++
Re: Re: [PATCH v6 00/18] MFD/ASoC/Input: TWL4030/TWL60X0 changes
Hi Tony, On Monday 27 June 2011 12:18:35 Tony Lindgren wrote: * Péter Ujfalusi peter.ujfal...@ti.com [110627 02:39]: Hi Tony, Samuel, Would you have time to take a look at this series? Looks good to me. If it conflicts with what we have queued in the devel-cleanup branch, I should probably queue it. There are conflicts in mach-omap2 (quite a lot), if I apply the series on top of the devel-cleanup branch. If there are no conflicts, then Samuel can queue it. I suppose this should then go through l-o... -- 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: Re: [PATCH v6 11/18] input: Add initial support for TWL6040 vibrator
Hello Dmitry, On Tuesday 21 June 2011 22:32:01 Dmitry Torokhov wrote: On Tue, Jun 21, 2011 at 04:39:09PM +0300, Peter Ujfalusi wrote: From: Misael Lopez Cruz misael.lo...@ti.com Add twl6040_vibra as a child of MFD device twl6040_codec. This implementation covers the PCM-to-PWM mode of TWL6040 vibrator module. Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Tejun Heo t...@kernel.org Peter, As Tejun mentioned, there is no difference between having a private workqueue created with alloc_workqueue() with default parameters and using system-wide workqueue. Therefore please use system-wide one. If your use shows that you indeed need high-priority workqueue it can be added later. I have replaced the singlethreaded wq with the call suggested by Tejun: https://lkml.org/lkml/2011/6/17/99 If this is a problem, I can rework this, and remove the code, which is not going to be needed, when the system_wq is in use, but I would like to keep the alloc_workqueue way, since it is going to be easier for us to experiment with parameters, if we face with issues. Otherwise: Acked-by: Dmitry Torokhov d...@mail.ru Please feel free to merge this code with the rest of TWL6040 patches (presumably throgh Samuel's MFD tree). Thank you, 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: Re: [PATCH v6 15/18] ASoC: twl6040: Remove pll and headset mode dependency
Hello Mark, On Tuesday 21 June 2011 19:35:05 Mark Brown wrote: On Tue, Jun 21, 2011 at 04:39:13PM +0300, Peter Ujfalusi wrote: From: Misael Lopez Cruz misael.lo...@ti.com Remove dependency between pll (hppll, lppll) and headset power mode (low-power, high-performance), as headset power mode can be used with any pll. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com but you should note that the code has been modified since Misael's original version. Oh. I did intended to put comments related to the changes has been done to this patch. Obviously I forgot to do that. I did not added your ack to this patch, since I knew that I have changed a bit more. Sorry. -- 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: Re: [alsa-devel] [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator
Hello Tejun, On Thursday 16 June 2011 16:06:00 Ujfalusi, Peter wrote: I suppose you meant alloc_workqueue()? :) Oh, yes. I mean that. Just avoid another series... I have looked at the alloc_workqueue, and I'm not really sure what parameters should I use. #define create_singlethread_workqueue(name) \ alloc_workqueue((name), WQ_UNBOUND | WQ_MEM_RECLAIM, 1) I would use something like this instead of create_singlethread_workqueue: alloc_workqueue(twl6040-vibra, WQ_UNBOUND | WQ_MEM_RECLAIM | WQ_HIGHPRI, 1); Is this correct? Thanks, 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: [PATCH v4 00/18] MFD/ASoC/Input: TWL4030/TWL60X0 changes
Hello Tony, Samuel, Mark, Liam. Did you got time to check the patches for your areas? I want to send the updated series with the change in the vibra driver (addressing comments from Dmitry, and Tejun), but I want to address your comments as well at the same time if any (or add you Ack). Thank you, Péter On Friday 10 June 2011 13:54:18 Ujfalusi, Peter wrote: Hello, Changes since v3: - patches generated with git format-patch -M to handle renames better - Included depending updates for twl6040 soc codec driver: - HS ramp configuration, new ABE dais, updated sample rate constraints - Configure the twl6040 codec on SDP4430 board Updated intro message from the v3 series: The series will do five major things, and they are in one series, because they pretty much depending on each other, so it is easier to handle them together. 1. Move the common pmic related configurations out from the board files. New twl-common.c/h file has been created for this purpose. OMAP3 board files received two patches (pdata, and regualtor changes), OMAP4 board files has been changed with one patch. 2. Rename the twl4030-codec MFD driver to twl4030-audio Since the ASoC multicomponent introduction (2.6.37) the twl4030-codec MFD dirver had been using twl4030-audio to register (twl4030-codec is the ASoC codec driver). The documentation refers to this part of twl as audio block, so it is better to rename the driver as well to avoid confusion. 3. Introduction of MFD driver for twl6040. The TWL6040 audio IC has codec and vibra functionality. Convert the existing ASoC codec driver to use the new MFD driver's interface. 4. Vibrator driver for TWL6040 (Input/ForceFeedback driver) The driver itself, and support for the vibrators in SDP4430 board. 5. Updates for twl6040 ASoC codec driver HS ramp configuration, new ABE dais, updated sample rate constraints, SDP4430 configuration. Regards, Peter -- 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: Re: [PATCH v4 00/18] MFD/ASoC/Input: TWL4030/TWL60X0 changes
Hello Mark, On Friday 17 June 2011 11:39:40 Mark Brown wrote: On Fri, Jun 17, 2011 at 01:06:19PM +0300, Péter Ujfalusi wrote: Hello Tony, Samuel, Mark, Liam. Did you got time to check the patches for your areas? I reviewed the first posting, did you do anything new? Yes I have added patches to the series for the codec part: 13-18 I have added your ack to patch 09 -- 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: Re: Re: [PATCH v4 00/18] MFD/ASoC/Input: TWL4030/TWL60X0 changes
On Friday 17 June 2011 11:51:28 Mark Brown wrote: Oh, gah. I'll dig them out of my mail folders - I wasn't reading the individual patches due to the repeated reposting. Sorry about that, I did mentioned this in the intro mail, when I introduced them. I should have made it more obvious for you. -- 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: Re: Re: [alsa-devel] [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator
On Friday 17 June 2011 11:43:32 Tejun Heo wrote: Just use the default params alloc_workqueue(twl6040-vibra, 0, 0); Thanks. I'll do this for the next posting Thanks, 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: Re: [alsa-devel] [PATCH v5 15/18] ASoC: twl6040: Remove pll and headset mode dependency
On Friday 17 June 2011 15:27:59 Mark Brown wrote: On Mon, Jun 13, 2011 at 07:37:47PM +0300, Peter Ujfalusi wrote: From: Misael Lopez Cruz misael.lo...@ti.com Remove dependency between pll (hppll, lppll) and headset power mode (low-power, high-performance), as headset power mode can be used with any pll. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com but... A new control is created to allow headset power mode configuration from userspace. Changing headset power mode during earpiece related usecases is not allowed as earpiece requires HS DAC in HP mode. Might be nicer to allow the user to set the control given that you'll just ignore the configured value anyway if it's not usable right now. Yeah, we can allow the change, but skip the register updates for use cases when it is not allowed. I did spot other issue related to this power mode handling: the DAPM event handler has been attached to HFDAC, and not to the HSDAC, so the refcounting is done for a wrong set of DAC... The HFDACs has no relationship with the Earpiece output (it is connected to HSDACL). -- 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: Re: [alsa-devel] [PATCH v5 14/18] ASoC: twl6040: Support other sample rates in constraints.
On Friday 17 June 2011 15:22:27 Mark Brown wrote: On Mon, Jun 13, 2011 at 07:37:46PM +0300, Peter Ujfalusi wrote: From: Liam Girdwood l...@ti.com Add other supported sample rates to LP and HP modes. Signed-off-by: Liam Girdwood l...@ti.com Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com This shouldn't be part of this series as far as I can tell, there's no textual link with the rest of it? I just did not wanted this patch to be buried within another patch. This patch fixes (completes) the supported sample rates for different power modes. I can remove it from the series and send it separately, but I would prefer if it is handled together with the rest of the changes. -- 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: Re: Re: Re: Re: Re: [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator
On Wednesday 15 June 2011 10:23:01 Tejun Heo wrote: On Wed, Jun 15, 2011 at 10:18:58AM +0200, Tejun Heo wrote: No human being can feel 120usec difference and I can't see how using HIGHPRI is justified here (which is what the code is doing _accidentally_ by using singlethread_workqueue). Ooh, one more thing, and even if you insist on using HIGHPRI (please don't), you don't need to create workqueue for each device. You can just create one for the whole driver in init and destroy it from exit. What matters is the HIGHPRI attribute of the workqueue. The number of workqueues is completely irrelevant. Fair enough. I'll move to create_workqueue. If we later find issues with this (in a 'live' system), we can figure out a way to fix it. Thank you for your time on this. I'll make the changes accordingly. Regards, 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: Re: Re: [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator
On Tuesday 14 June 2011 08:34:00 Tejun Heo wrote: Yeap, using a separate workqueue doesn't do anything for latency unless WQ_HIGHPRI and/or WQ_CPU_INTENSIVE is used; however, _please_ stay away from it unless absolutely sure it's necessary (ie. unless you can pin point to where latency is coming from - even in that case, the thing which induces the latency probably is the one which should be fixed). The latency in most cases comes from the fact, that we are running an embedded system. Number of peripherals are connected via I2C, these drivers are using workqueues to communicate with the IC. Since only one device can communicate through I2C at the time. This is basically the source of the latency. It does not really matter, if the devices are on the same I2C bus or not, it is enough if two work belonging to device, which happens to be on the same I2C bus, and the first work in the queue takes long time to complete (reading back bigger chunk of info, configuring, etc). Even if we could schedule the second work on the other CPU, it will be put waiting till the I2C bus is free, so both CPU core has work assigned, the first is keeping the I2C bus, the other waits for the I2C bus, and the third is waiting to be scheduled (which will be happening, when the first work finished). IMHO the tactile feedback (vibra) should have an excuse to have separate WQ to avoid latency spikes. I agree, that most cases we can use the global wq. CMWQ is pretty good at keeping latency low unless something is consuming large amount of CPU cycles and those work items are marked WQ_CPU_INTENSIVE, not the other way around and WQ_HIGHPRI is for things like MCE error reporting. So this is not really about CPU utilization, it is due to the wide variety of peripherals connected to an embedded system. -- 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: Re: Re: Re: [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator
On Tuesday 14 June 2011 09:31:30 Tejun Heo wrote: Thanks for the explanation. I have a couple more questions. * While transferring data from I2C, I suppose the work item is fully occupying the CPU? Not exactly on OMAP platforms at least. We do not have busy looping in low level driver (we wait with wait_for_completion_timeout for the transfer to be done), so scheduling on the same CPU can be possible. If so, how long delay are we talking about? Millisecs? It is hard to predict, but it can be few tens of ms for one device, if we have several devices on the same bus (which we tend to have), and they want to read/write something at the same time we can see hundred(s) ms in total - it is rare to happen, and hard to reproduce, but it does happen for sure. * You said that the if one task is accessing I2C bus, the other would wait even if scheduled on a different CPU. Is access to I2C bus protected with a spinlock? At the bottom it is using rt_mutex_lock/unlick to protect the bus. And yes, the others need to wait till the ongoing transfer has been finished. Also, as it's currently implemented, single threaded wq's effectively bypass concurrency level control. This is an implementation detail which may change in the future, so even if you're seeing lower latency by using a separate single threaded wq, it's an accident and if you require lower latency you should be expressing the requirement explicitly. I see, do you have suggestion to which would be best for this kind of scenarios. In most cases global wq would be OK for this, but time-to-time we face with sudden latency spikes, which makes the user experience really bad. Currently with singlethreaded wq we can avoid these spikes. Thank you, 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: Re: Re: Re: Re: [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator
On Tuesday 14 June 2011 10:18:36 Tejun Heo wrote: I see, so IIUC, * If it's using mutex and not holding CPU for the whole duration, you shouldn't need to do anything special for latency for other work items. Workqueue code will start executing other work items as soon as the I2C work item goes to sleep. I see. * If I2C work item is burning CPU cycles for the whole duration which may stretch to tens / few hundreds millsecs, 1. it's doing something quite wrong, 2. should be marked WQ_CPU_INTENSIVE. So, if something needs to be modified, it's the I2C stuff, not the vibrator driver. If I2C stuff isn't doing something wonky, there shouldn't be a latency problem to begin with. In case of OMAP the former is the case regarding to I2C. However I did run a short experiments regarding to latencies: With create_singlethread_workqueue : Jun 14 12:54:30 omap-gentoo kernel: [ 211.269531] vibra scheduling time: 30 usec Jun 14 12:54:30 omap-gentoo kernel: [ 211.300811] vibra scheduling time: 30 usec Jun 14 12:54:33 omap-gentoo kernel: [ 214.419006] vibra scheduling time: 31 usec Jun 14 12:54:34 omap-gentoo kernel: [ 214.980987] vibra scheduling time: 30 usec Jun 14 12:54:35 omap-gentoo kernel: [ 215.762115] vibra scheduling time: 30 usec Jun 14 12:54:35 omap-gentoo kernel: [ 215.816650] vibra scheduling time: 30 usec Jun 14 12:54:35 omap-gentoo kernel: [ 215.871337] vibra scheduling time: 61 usec Jun 14 12:54:35 omap-gentoo kernel: [ 215.926025] vibra scheduling time: 61 usec Jun 14 12:54:35 omap-gentoo kernel: [ 215.980743] vibra scheduling time: 61 usec Jun 14 12:54:35 omap-gentoo kernel: [ 216.035430] vibra scheduling time: 61 usec Jun 14 12:54:38 omap-gentoo kernel: [ 219.425659] vibra scheduling time: 31 usec Jun 14 12:54:40 omap-gentoo kernel: [ 220.981658] vibra scheduling time: 31 usec Jun 14 12:54:44 omap-gentoo kernel: [ 224.692504] vibra scheduling time: 30 usec Jun 14 12:54:44 omap-gentoo kernel: [ 225.067138] vibra scheduling time: 30 usec With create_workqueue : Jun 14 12:05:00 omap-gentoo kernel: [ 304.965393] vibra scheduling time: 183 usec Jun 14 12:05:01 omap-gentoo kernel: [ 305.964996] vibra scheduling time: 61 usec Jun 14 12:05:03 omap-gentoo kernel: [ 307.684082] vibra scheduling time: 152 usec Jun 14 12:05:06 omap-gentoo kernel: [ 310.972778] vibra scheduling time: 30 usec Jun 14 12:05:08 omap-gentoo kernel: [ 312.683715] vibra scheduling time: 61 usec Jun 14 12:05:10 omap-gentoo kernel: [ 314.785675] vibra scheduling time: 183 usec Jun 14 12:05:15 omap-gentoo kernel: [ 319.800903] vibra scheduling time: 61 usec Jun 14 12:05:16 omap-gentoo kernel: [ 320.738403] vibra scheduling time: 30 usec Jun 14 12:05:16 omap-gentoo kernel: [ 320.793090] vibra scheduling time: 61 usec Jun 14 12:05:16 omap-gentoo kernel: [ 320.847778] vibra scheduling time: 61 usec Jun 14 12:05:16 omap-gentoo kernel: [ 320.902465] vibra scheduling time: 61 usec Jun 14 12:05:16 omap-gentoo kernel: [ 320.957153] vibra scheduling time: 61 usec Jun 14 12:05:16 omap-gentoo kernel: [ 320.996185] vibra scheduling time: 31 usec This is in a system, where I do not have any other drivers on I2C bus, and I have generated some load with this command: grep -r generate_load /* So, I have some CPU, and IO load as well. At the end the differences are not that big, but with create_singlethread_workqueue I can see less spikes. This is with 3.0-rc2 kernel I still think, that there is a place for the create_singlethread_workqueue, and the tactile feedback needs such a thing. As I recall correctly this was the reason to use create_singlethread_workqueue in the twl4030-vibra driver as well (there were latency issues without it). -- 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: Re: [PATCH] OMAP4: McBSP: Clear rx_irq at probe time
Hi Tony, On Monday 13 June 2011 15:35:43 Tony Lindgren wrote: Sure we can merge fixes Can you take this patch forward? but let's get the move done before adding new features. What is considered a new feature here? Is it a new feature, if I fix the McBSP for OMAP4 (FIFO usage, and small updates)? We have discussion ongoing about the mcbsp code move, and so far the current understanding/plan is (Jarkko/Liam correct me if I'm wrong): - Fix the OMAP4 support - move the code under sound/soc/omap/ - the reason for this is that McBSP block can be only used for streaming type of modes (from omap2430 onwards McBSP does not have clock stop functionality). This makes other type of usage hard to say the least. - Clean up the code (remove the SPI mode, remove unused code paths at the same time) - Consolidate the interface for audio only use - Only OMAP3 has sidetone (on OMAP2 EAC block has the sidetone), might need some change, but I think the current way can be reused. In this way we are not going to hide the OMAP4 fixes with the code move/consolidation effort, so one can track what has been done, and why. Opinions? -- 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 1/2] omap: mcbsp: Drop SPI mode support
On Tuesday 14 June 2011 13:23:51 Jarkko Nikula wrote: We haven't seen any use for the SPI API in McBSP driver over the years. More over, Peter Ujfalusi peter.ujfal...@ti.com noticed that SPI mode is not even supported since OMAP2430 so it's very unlikely that we'll see any use for it in the future either. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Either now or later, but for both: Acked-by: Peter Ujfalusi peter.ujfal...@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: Re: [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator
On Sunday 12 June 2011 01:18:54 Dmitry Torokhov wrote:
+static void twl6040_vibra_enable(struct vibra_info *info)
+{
+ struct twl6040 *twl6040 = info-twl6040;
+ int ret = 0;
Initialization is not needed.
True.
+static void vibra_play_work(struct work_struct *work)
+{
+ struct vibra_info *info = container_of(work,
+ struct vibra_info, play_work);
+
+ mutex_lock(info-mutex);
+
+ if (info-weak_speed || info-strong_speed) {
+ if (!info-enabled)
+ twl6040_vibra_enable(info);
+
+ twl6040_vibra_set_effect(info);
+ } else if (info-enabled)
+ twl6040_vibra_disable(info);
Why do we play with enabling/disabling the device here? Nobody can
request playing of an effect unless the device has been opened so if we
manage power state in open/close methods we should not be doing it here
I think.
We want to preserve as much power as we can.
So if application opens the driver, but it is not requesting to play any
effect we still keep the device turned off.
When application request for stopping the effect without closing the device,
we turn off things in a similar way.
The twl4030-vibra driver has been implemented in this way as well.
+
+ mutex_unlock(info-mutex);
+}
...
+static int twl6040_vibra_open(struct input_dev *input)
+{
+ struct vibra_info *info = input_get_drvdata(input);
+
+ info-workqueue = create_singlethread_workqueue(vibra);
+ if (info-workqueue == NULL) {
+ dev_err(input-dev, couldn't create workqueue\n);
+ return -ENOMEM;
+ }
Why do we need to create a separate workqueue? With arrival of CWQ
it looks like we should be able to use one of the system-wide
workqueues for this.
The reason for this is to ensure that we have the lowest latency as possible
in most case. In the embedded devices we use the vibra for tactile type of
feedbacks as well, where few tens of ms delay can be felt.
+
+ return 0;
+}
+
+static void twl6040_vibra_close(struct input_dev *input)
+{
+ struct vibra_info *info = input_get_drvdata(input);
+
+ cancel_work_sync(info-play_work);
+ INIT_WORK(info-play_work, vibra_play_work);
+ destroy_workqueue(info-workqueue);
+ info-workqueue = NULL;
+
+ mutex_lock(info-mutex);
+
+ if (info-enabled)
+ twl6040_vibra_disable(info);
+
+ mutex_unlock(info-mutex);
+}
+
+#if CONFIG_PM
CONFIG_PM_SLEEP.
OK, will be fixed.
+static int twl6040_vibra_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct vibra_info *info = platform_get_drvdata(pdev);
+
+ mutex_lock(info-mutex);
+
+ if (info-enabled)
+ twl6040_vibra_disable(info);
+
+ mutex_unlock(info-mutex);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(twl6040_vibra_pm_ops,
+ twl6040_vibra_suspend, NULL);
Move twl6040_vibra_pm_ops definition out of the #ifdef block so you
won't need to protect it use with ifdefs later.
Thanks, I have change this.
+#endif
...
+static int __devexit twl6040_vibra_remove(struct platform_device *pdev)
+{
+ struct vibra_info *info = platform_get_drvdata(pdev);
+
+ twl6040_power(info-twl6040, 0);
If we ensure that device is powered off until open() is called, and
also powered off when close() is called, then we do not need to switch
off power here.
True, removed.
Thanks.
--
Dmitry
Thanks for the comments. I will update the series.
--
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: HELP:How to power down TWL5030 Voice/Bluetooth sidetone PGA?
2011/6/10 Péter Ujfalusi peter.ujfal...@ti.com: 1. when use Headset: uplink routing:HSMIC -- AVTXR2PGA AVTXL2PGA -- VDXS VDXM -- PCM_VDX downlink routing:PCM_VDR -- VDR -- VRXPGA Fine gain -- DAC voice -- VDL_GAIN Analog PGA -- HSOL/HSOR Thanks I check the loopbacks,it seems that all Loopbacks have been disabled. bash-3.2# alsa_amixer |grep Loopback Simple mixer control 'Left Digital Loopback',0 Simple mixer control 'Left1 Analog Loopback',0 Simple mixer control 'Left2 Analog Loopback',0 Simple mixer control 'Right Digital Loopback',0 Simple mixer control 'Right1 Analog Loopback',0 Simple mixer control 'Right2 Analog Loopback',0 Simple mixer control 'Voice Analog Loopback',0 Simple mixer control 'Voice Digital Loopback',0 Can you check with: amixer | grep -A 6 Loopback The sidetone is become louder if I increase the VSTPGA, and when I increase the VDL_GAIN Analog PGA,the sidetone is become louder too. But the VRXPGA seems don't affect the sidetone,so I think VSTPGA cause the sidetone. 2.when use Bluetooth: uplink routing:BT_PCM_VDR -- BTTXPGA -- VDXM -- PCM_VDX downlink routing:PCM_VDR -- VDR -- BTRXPGA -- BT_PCM_VDX When use Bluetooth interface,I don't know if something else can cause sidetone except BTSTPGA. I don't have a board, which have this feature, but I'll check the TRM and the code, if I can find something. Probably worth to find the ERRATA document as well... -- 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: [PATCH v3 06/12] MFD: twl4030-codec - twl4030-audio: Rename the driver
On Thursday 09 June 2011 22:37:28 Arnd Bergmann wrote: Better use the -M flag to git-format-patch when moving files, to make it obvious what has or has not changed, and to reduce the size of the email. I tend to forgot the -M flag, thanks. Also, shouldn't this file go into the sound/soc/ directory? It seems that this is really the device driver, not part of the multi-function layer. This driver is the MFD core part for the audio block within the twl4030 series pmic. We have the slave drivers under sound/soc/codecs/twl4030.c and drivers/input/misc/twl4030-vibra.c. The audio block has codec, and vibra functionality, and we need to have this driver to properly manage this block within twl. -- 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
