Hi,
I only send this to the kernel@pyra-handheld.com for testing. Tero's patch for sure needs to be split up for upstream and needs commit message
As for the rest: I think both the mfd and ASoC patch can go upstream if the tesing goes fine.
Some notes: the MCLK for HPPLL is going to be handled runtime and it is only enabled when it has been requested - during audio playback/capture when no audio is running we switch back to LPPLL. According to the datasheet it provides a bit lower power consumption.
The switch between the LPPLL and HPPLL is not possible during active audio, the mixer change will take efect after audio stop and restart. No change in this.
Tested on top of: next-20160509
Regards, Peter ---- Peter Ujfalusi (3): mfd: twl6040: Handle mclk (for HPPLL) via clock API ASoC: twl6040: Select LPPLL during standby ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040
Tero Kristo (1): ARM: omap5: add support for fref_xtal_ck
Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++---- drivers/clk/ti/clk-54xx.c | 1 + drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/clk/ti.h | 1 + include/linux/mfd/twl6040.h | 3 ++- sound/soc/codecs/twl6040.c | 12 ++++++---- 10 files changed, 86 insertions(+), 19 deletions(-)
From: Tero Kristo t-kristo@ti.com
Signed-off-by: Tero Kristo t-kristo@ti.com Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++++++---- drivers/clk/ti/clk-54xx.c | 1 + include/linux/clk/ti.h | 1 + 5 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 84c10195e79b..6fef4faf5610 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -277,6 +277,28 @@ pinctrl-single,register-width = <16>; pinctrl-single,function-mask = <0x7fff>; }; + + omap5_scm_wkup_pad_conf: omap5_scm_wkup_pad_conf@cda0 { + compatible = "ti,omap5-scm-wkup-pad-conf", + "simple-bus"; + reg = <0xcda0 0x60>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xcda0 0x60>; + + scm_wkup_pad_conf: scm_conf@0 { + compatible = "syscon", "simple-bus"; + reg = <0x0 0x60>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x60>; + + scm_wkup_pad_conf_clocks: clocks@0 { + #address-cells = <1>; + #size-cells = <0>; + }; + }; + }; };
ocmcram: ocmcram@40300000 { diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi index 4899c2359d0a..a8153b433f96 100644 --- a/arch/arm/boot/dts/omap54xx-clocks.dtsi +++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi @@ -1388,3 +1388,13 @@ reg = <0x021c>; }; }; + +&scm_wkup_pad_conf_clocks { + fref_xtal_ck: fref_xtal_ck { + #clock-cells = <0>; + compatible = "ti,gate-clock"; + clocks = <&sys_clkin>; + ti,bit-shift = <28>; + reg = <0x14>; + }; +}; diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 1662071bb2cc..595664173e49 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -623,6 +623,7 @@ void __init omap3_ctrl_init(void)
struct control_init_data { int index; + void __iomem *mem; s16 offset; };
@@ -635,6 +636,10 @@ static const struct control_init_data omap2_ctrl_data = { .offset = -OMAP2_CONTROL_GENERAL, };
+static const struct control_init_data ctrl_aux_data = { + .index = TI_CLKM_CTRL_AUX, +}; + static const struct of_device_id omap_scrm_dt_match_table[] = { { .compatible = "ti,am3-scm", .data = &ctrl_data }, { .compatible = "ti,am4-scm", .data = &ctrl_data }, @@ -644,6 +649,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] = { { .compatible = "ti,dm816-scrm", .data = &ctrl_data }, { .compatible = "ti,omap4-scm-core", .data = &ctrl_data }, { .compatible = "ti,omap5-scm-core", .data = &ctrl_data }, + { .compatible = "ti,omap5-scm-wkup-pad-conf", .data = &ctrl_aux_data }, { .compatible = "ti,dra7-scm-core", .data = &ctrl_data }, { } }; @@ -660,15 +666,21 @@ int __init omap2_control_base_init(void) struct device_node *np; const struct of_device_id *match; struct control_init_data *data; + void __iomem *mem;
for_each_matching_node_and_match(np, omap_scrm_dt_match_table, &match) { data = (struct control_init_data *)match->data;
- omap2_ctrl_base = of_iomap(np, 0); - if (!omap2_ctrl_base) + mem = of_iomap(np, 0); + if (!mem) return -ENOMEM;
- omap2_ctrl_offset = data->offset; + if (data->index == TI_CLKM_CTRL) { + omap2_ctrl_base = mem; + omap2_ctrl_offset = data->offset; + } + + data->mem = mem; }
return 0; @@ -713,7 +725,7 @@ int __init omap_control_init(void) } else { /* No scm_conf found, direct access */ ret = omap2_clk_provider_init(np, data->index, NULL, - omap2_ctrl_base); + data->mem); if (ret) return ret; } diff --git a/drivers/clk/ti/clk-54xx.c b/drivers/clk/ti/clk-54xx.c index 294bc03ec067..20f6985a80ef 100644 --- a/drivers/clk/ti/clk-54xx.c +++ b/drivers/clk/ti/clk-54xx.c @@ -222,6 +222,7 @@ static struct ti_dt_clk omap54xx_clks[] = { DT_CLK("4013a000.timer", "timer_sys_ck", "dss_syc_gfclk_div"), DT_CLK("4013c000.timer", "timer_sys_ck", "dss_syc_gfclk_div"), DT_CLK("4013e000.timer", "timer_sys_ck", "dss_syc_gfclk_div"), + DT_CLK(NULL, "fref_xtal_ck", "fref_xtal_ck"), { .node_name = NULL }, };
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h index 6110fe09ed18..5431f17a36bc 100644 --- a/include/linux/clk/ti.h +++ b/include/linux/clk/ti.h @@ -197,6 +197,7 @@ enum { TI_CLKM_PRM, TI_CLKM_SCRM, TI_CLKM_CTRL, + TI_CLKM_CTRL_AUX, TI_CLKM_PLLSS, CLK_MAX_MEMMAPS };
Support for mclk handling via clock API
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/mfd/twl6040.h | 3 ++- 3 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt index a41157b5d930..e6afdfa3543d 100644 --- a/Documentation/devicetree/bindings/mfd/twl6040.txt +++ b/Documentation/devicetree/bindings/mfd/twl6040.txt @@ -19,8 +19,8 @@ Required properties:
Optional properties, nodes: - enable-active-high: To power on the twl6040 during boot. -- clocks: phandle to the clk32k clock provider -- clock-names: Must be "clk32k" +- clocks: phandle to the clk32k and/or to mclk clock provider +- clock-names: Must be "clk32k" for the 32K clock and "mclk" for the MCLK.
Vibra functionality Required properties: diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 08a693cd38cc..bcf2bc34a915 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -291,7 +291,7 @@ int twl6040_power(struct twl6040 *twl6040, int on) if (twl6040->power_count++) goto out;
- clk_prepare_enable(twl6040->clk32k); + clk_prepare_enable(twl6040->clk32k_clk);
/* Allow writes to the chip */ regcache_cache_only(twl6040->regmap, false); @@ -349,7 +349,10 @@ int twl6040_power(struct twl6040 *twl6040, int on) twl6040->sysclk = 0; twl6040->mclk = 0;
- clk_disable_unprepare(twl6040->clk32k); + if (twl6040->pll == TWL6040_SYSCLK_SEL_HPPLL) + clk_disable_unprepare(twl6040->mclk_clk); + + clk_disable_unprepare(twl6040->clk32k_clk); }
out: @@ -421,6 +424,8 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, ret = -EINVAL; goto pll_out; } + + clk_disable_unprepare(twl6040->mclk_clk); break; case TWL6040_SYSCLK_SEL_HPPLL: /* high-performance PLL can provide only 19.2 MHz */ @@ -462,6 +467,9 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, goto pll_out; }
+ /* When switching to HPPLL, enable the mclk first */ + if (pll_id != twl6040->pll) + clk_prepare_enable(twl6040->mclk_clk); /* * enable clock slicer to ensure input waveform is * square @@ -645,12 +653,20 @@ static int twl6040_probe(struct i2c_client *client,
i2c_set_clientdata(client, twl6040);
- twl6040->clk32k = devm_clk_get(&client->dev, "clk32k"); - if (IS_ERR(twl6040->clk32k)) { - if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER) + twl6040->clk32k_clk = devm_clk_get(&client->dev, "clk32k"); + if (IS_ERR(twl6040->clk32k_clk)) { + if (PTR_ERR(twl6040->clk32k_clk) == -EPROBE_DEFER) return -EPROBE_DEFER; dev_info(&client->dev, "clk32k is not handled\n"); - twl6040->clk32k = NULL; + twl6040->clk32k_clk = NULL; + } + + twl6040->mclk_clk = devm_clk_get(&client->dev, "mclk"); + if (IS_ERR(twl6040->mclk_clk)) { + if (PTR_ERR(twl6040->mclk_clk) == -EPROBE_DEFER) + return -EPROBE_DEFER; + dev_info(&client->dev, "mclk is not handled\n"); + twl6040->mclk_clk = NULL; }
twl6040->supplies[0].supply = "vio"; diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h index 8f9fc3d26e6d..a7c50e54f3e0 100644 --- a/include/linux/mfd/twl6040.h +++ b/include/linux/mfd/twl6040.h @@ -224,7 +224,8 @@ struct twl6040 { struct regmap *regmap; struct regmap_irq_chip_data *irq_data; struct regulator_bulk_data supplies[2]; /* supplies for vio, v2v1 */ - struct clk *clk32k; + struct clk *clk32k_clk; + struct clk *mclk_clk; struct mutex mutex; struct mutex irq_mutex; struct mfd_cell cells[TWL6040_CELLS];
Hi Peter, what happened with these patches?
We have them as additions in our Pyra kernel (and they seem to work).
But they did not yet arrive at linux-next.
At least "ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040" which I have checked.
BR, Nikolaus
Am 10.05.2016 um 11:11 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
Support for mclk handling via clock API
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com
Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/mfd/twl6040.h | 3 ++- 3 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt index a41157b5d930..e6afdfa3543d 100644 --- a/Documentation/devicetree/bindings/mfd/twl6040.txt +++ b/Documentation/devicetree/bindings/mfd/twl6040.txt @@ -19,8 +19,8 @@ Required properties:
Optional properties, nodes:
- enable-active-high: To power on the twl6040 during boot.
-- clocks: phandle to the clk32k clock provider -- clock-names: Must be "clk32k" +- clocks: phandle to the clk32k and/or to mclk clock provider +- clock-names: Must be "clk32k" for the 32K clock and "mclk" for the MCLK.
Vibra functionality Required properties: diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 08a693cd38cc..bcf2bc34a915 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -291,7 +291,7 @@ int twl6040_power(struct twl6040 *twl6040, int on) if (twl6040->power_count++) goto out;
clk_prepare_enable(twl6040->clk32k);
clk_prepare_enable(twl6040->clk32k_clk);/* Allow writes to the chip */ regcache_cache_only(twl6040->regmap, false);
@@ -349,7 +349,10 @@ int twl6040_power(struct twl6040 *twl6040, int on) twl6040->sysclk = 0; twl6040->mclk = 0;
clk_disable_unprepare(twl6040->clk32k);
if (twl6040->pll == TWL6040_SYSCLK_SEL_HPPLL)clk_disable_unprepare(twl6040->mclk_clk);clk_disable_unprepare(twl6040->clk32k_clk);out: @@ -421,6 +424,8 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, ret = -EINVAL; goto pll_out; }
clk_disable_unprepare(twl6040->mclk_clk);@@ -462,6 +467,9 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, goto pll_out; }
/* When switching to HPPLL, enable the mclk first */if (pll_id != twl6040->pll)clk_prepare_enable(twl6040->mclk_clk); /* * enable clock slicer to ensure input waveform is * square@@ -645,12 +653,20 @@ static int twl6040_probe(struct i2c_client *client,
i2c_set_clientdata(client, twl6040);
- twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
- if (IS_ERR(twl6040->clk32k)) {
if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
- twl6040->clk32k_clk = devm_clk_get(&client->dev, "clk32k");
- if (IS_ERR(twl6040->clk32k_clk)) {
if (PTR_ERR(twl6040->clk32k_clk) == -EPROBE_DEFER) return -EPROBE_DEFER;
twl6040->clk32k = NULL;
twl6040->clk32k_clk = NULL;}
twl6040->mclk_clk = devm_clk_get(&client->dev, "mclk");
if (IS_ERR(twl6040->mclk_clk)) {
if (PTR_ERR(twl6040->mclk_clk) == -EPROBE_DEFER)return -EPROBE_DEFER;dev_info(&client->dev, "mclk is not handled\n");twl6040->mclk_clk = NULL;}
twl6040->supplies[0].supply = "vio";
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h index 8f9fc3d26e6d..a7c50e54f3e0 100644 --- a/include/linux/mfd/twl6040.h +++ b/include/linux/mfd/twl6040.h @@ -224,7 +224,8 @@ struct twl6040 { struct regmap *regmap; struct regmap_irq_chip_data *irq_data; struct regulator_bulk_data supplies[2]; /* supplies for vio, v2v1 */
- struct clk *clk32k;
- struct clk *clk32k_clk;
- struct clk *mclk_clk; struct mutex mutex; struct mutex irq_mutex; struct mfd_cell cells[TWL6040_CELLS];
-- 2.8.2
On 09/17/16 13:42, H. Nikolaus Schaller wrote:
Hi Peter, what happened with these patches?
We have them as additions in our Pyra kernel (and they seem to work).
But they did not yet arrive at linux-next.
At least "ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040" which I have checked.
The MFD/ASoC parts are in for some time, but these patches from Tero still missing:
ARM: omap2+: control: add support for auxiliary control module instances ARM: dts: omap5: add support for control module wkup pad config ARM: OMAP5: control: add support for control module wkup pad config ARM: dts: omap5: add fref_xtal_ck support ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040
Tero: would you be so kind and resend them?
BR, Nikolaus
Am 10.05.2016 um 11:11 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
Support for mclk handling via clock API
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com
Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/mfd/twl6040.h | 3 ++- 3 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt index a41157b5d930..e6afdfa3543d 100644 --- a/Documentation/devicetree/bindings/mfd/twl6040.txt +++ b/Documentation/devicetree/bindings/mfd/twl6040.txt @@ -19,8 +19,8 @@ Required properties:
Optional properties, nodes:
- enable-active-high: To power on the twl6040 during boot.
-- clocks: phandle to the clk32k clock provider -- clock-names: Must be "clk32k" +- clocks: phandle to the clk32k and/or to mclk clock provider +- clock-names: Must be "clk32k" for the 32K clock and "mclk" for the MCLK.
Vibra functionality Required properties: diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 08a693cd38cc..bcf2bc34a915 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -291,7 +291,7 @@ int twl6040_power(struct twl6040 *twl6040, int on) if (twl6040->power_count++) goto out;
clk_prepare_enable(twl6040->clk32k);
clk_prepare_enable(twl6040->clk32k_clk);/* Allow writes to the chip */ regcache_cache_only(twl6040->regmap, false);
@@ -349,7 +349,10 @@ int twl6040_power(struct twl6040 *twl6040, int on) twl6040->sysclk = 0; twl6040->mclk = 0;
clk_disable_unprepare(twl6040->clk32k);
if (twl6040->pll == TWL6040_SYSCLK_SEL_HPPLL)clk_disable_unprepare(twl6040->mclk_clk);clk_disable_unprepare(twl6040->clk32k_clk);out: @@ -421,6 +424,8 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, ret = -EINVAL; goto pll_out; }
clk_disable_unprepare(twl6040->mclk_clk);@@ -462,6 +467,9 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, goto pll_out; }
/* When switching to HPPLL, enable the mclk first */if (pll_id != twl6040->pll)clk_prepare_enable(twl6040->mclk_clk); /* * enable clock slicer to ensure input waveform is * square@@ -645,12 +653,20 @@ static int twl6040_probe(struct i2c_client *client,
i2c_set_clientdata(client, twl6040);
- twl6040->clk32k = devm_clk_get(&client->dev, "clk32k");
- if (IS_ERR(twl6040->clk32k)) {
if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
- twl6040->clk32k_clk = devm_clk_get(&client->dev, "clk32k");
- if (IS_ERR(twl6040->clk32k_clk)) {
if (PTR_ERR(twl6040->clk32k_clk) == -EPROBE_DEFER) return -EPROBE_DEFER;
twl6040->clk32k = NULL;
twl6040->clk32k_clk = NULL;}
twl6040->mclk_clk = devm_clk_get(&client->dev, "mclk");
if (IS_ERR(twl6040->mclk_clk)) {
if (PTR_ERR(twl6040->mclk_clk) == -EPROBE_DEFER)return -EPROBE_DEFER;dev_info(&client->dev, "mclk is not handled\n");twl6040->mclk_clk = NULL;}
twl6040->supplies[0].supply = "vio";
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h index 8f9fc3d26e6d..a7c50e54f3e0 100644 --- a/include/linux/mfd/twl6040.h +++ b/include/linux/mfd/twl6040.h @@ -224,7 +224,8 @@ struct twl6040 { struct regmap *regmap; struct regmap_irq_chip_data *irq_data; struct regulator_bulk_data supplies[2]; /* supplies for vio, v2v1 */
- struct clk *clk32k;
- struct clk *clk32k_clk;
- struct clk *mclk_clk; struct mutex mutex; struct mutex irq_mutex; struct mfd_cell cells[TWL6040_CELLS];
-- 2.8.2
When the codec is in standby we do not need to keep the HPPLL active.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- sound/soc/codecs/twl6040.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/twl6040.c b/sound/soc/codecs/twl6040.c index bc3de2e844e6..7a744b581cc1 100644 --- a/sound/soc/codecs/twl6040.c +++ b/sound/soc/codecs/twl6040.c @@ -824,7 +824,7 @@ static int twl6040_set_bias_level(struct snd_soc_codec *codec, { struct twl6040 *twl6040 = codec->control_data; struct twl6040_data *priv = snd_soc_codec_get_drvdata(codec); - int ret; + int ret = 0;
switch (level) { case SND_SOC_BIAS_ON: @@ -832,12 +832,16 @@ static int twl6040_set_bias_level(struct snd_soc_codec *codec, case SND_SOC_BIAS_PREPARE: break; case SND_SOC_BIAS_STANDBY: - if (priv->codec_powered) + if (priv->codec_powered) { + /* Select low power PLL in standby */ + ret = twl6040_set_pll(twl6040, TWL6040_SYSCLK_SEL_LPPLL, + 32768, 19200000); break; + }
ret = twl6040_power(twl6040, 1); if (ret) - return ret; + break;
priv->codec_powered = 1;
@@ -853,7 +857,7 @@ static int twl6040_set_bias_level(struct snd_soc_codec *codec, break; }
- return 0; + return ret; }
static int twl6040_startup(struct snd_pcm_substream *substream,
it is used for hppll.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index a3a631fb77aa..4caad4dc5d41 100644 --- a/arch/arm/boot/dts/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -649,8 +649,8 @@ v2v1-supply = <&smps9_reg>; enable-active-high;
- clocks = <&clk32kgaudio>; - clock-names = "clk32k"; + clocks = <&clk32kgaudio>, <&fref_xtal_ck>; + clock-names = "clk32k", "mclk"; }; };
Hi Peter,
Am 10.05.2016 um 11:11 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
Hi,
I only send this to the kernel@pyra-handheld.com for testing. Tero's patch for sure needs to be split up for upstream and needs commit message
As for the rest: I think both the mfd and ASoC patch can go upstream if the tesing goes fine.
Some notes: the MCLK for HPPLL is going to be handled runtime and it is only enabled when it has been requested - during audio playback/capture when no audio is running we switch back to LPPLL. According to the datasheet it provides a bit lower power consumption.
The switch between the LPPLL and HPPLL is not possible during active audio, the mixer change will take efect after audio stop and restart. No change in this.
Tested on top of: next-20160509
I have integrated your patches and they appear to work :)
I can check with "devmem2 0x4AE0CDB4" that it changes the ckobuffer from 0x0 to 0x10000000 and back. So this part works fine :)
On the headset port I get what I regard as "good quality" (audiophiles may disagree...).
The handsfree speakers have big distortion (scrachy, clipped). It did have this before as well but I have the impression that it even got worse. I remember our first experiments with the Pandaboard where it did work (I have to set it up again for comparisons).
Sometimes I get a data block of random noise... But that might be DMA/interrupt related buffer-underrun, although I do not see any significant messages. Or sox/play has a bug.
In my experiments, playing music is done by sox/play:
play somefile.mp3 remix 1 1 2 2
And I have:
root@letux:~# amixer get "Headset Power Mode" Simple mixer control 'Headset Power Mode',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~# amixer get "PLL Selection" Simple mixer control 'PLL Selection',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~#
Is this ok?
Anyways, setting both to low power/performance has no audible effect.
BR and thanks, Nikolaus
Regards, Peter
Peter Ujfalusi (3): mfd: twl6040: Handle mclk (for HPPLL) via clock API ASoC: twl6040: Select LPPLL during standby ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040
Tero Kristo (1): ARM: omap5: add support for fref_xtal_ck
Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++---- drivers/clk/ti/clk-54xx.c | 1 + drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/clk/ti.h | 1 + include/linux/mfd/twl6040.h | 3 ++- sound/soc/codecs/twl6040.c | 12 ++++++---- 10 files changed, 86 insertions(+), 19 deletions(-)
-- 2.8.2
On 05/10/16 16:29, H. Nikolaus Schaller wrote:
Hi Peter,
Am 10.05.2016 um 11:11 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
Hi,
I only send this to the kernel@pyra-handheld.com for testing. Tero's patch for sure needs to be split up for upstream and needs commit message
As for the rest: I think both the mfd and ASoC patch can go upstream if the tesing goes fine.
Some notes: the MCLK for HPPLL is going to be handled runtime and it is only enabled when it has been requested - during audio playback/capture when no audio is running we switch back to LPPLL. According to the datasheet it provides a bit lower power consumption.
The switch between the LPPLL and HPPLL is not possible during active audio, the mixer change will take efect after audio stop and restart. No change in this.
Tested on top of: next-20160509
I have integrated your patches and they appear to work :)
I can check with "devmem2 0x4AE0CDB4" that it changes the ckobuffer from 0x0 to 0x10000000 and back. So this part works fine :)
Great, thanks! I will prepare the patches for upstream for the twl6040.
On the headset port I get what I regard as "good quality" (audiophiles may disagree...).
Yeah, twl6040 is not that bad in this regards IMHO.
The handsfree speakers have big distortion (scrachy, clipped). It did have this before as well but I have the impression that it even got worse. I remember our first experiments with the Pandaboard where it did work (I have to set it up again for comparisons).
Hrm, but this is unrelated to this series, right? Too high gain for the HF path? I can not test HF on OMAP5, only the line-out and that sounds OK. Since the Line-out is the same audio signal w/o going through the HF drivers it might be a good idea to see if that also have distortion. If not than the path from HF drivers to the speaker is the one which adds the distortion. Most likely.
Sometimes I get a data block of random noise... But that might be DMA/interrupt related buffer-underrun, although I do not see any significant messages. Or sox/play has a bug.
Have been playing 4 channel wav with aplay for about an hour and I have not experienced any noise (via line-out + headset), so not sure what could cause it.
In my experiments, playing music is done by sox/play:
play somefile.mp3 remix 1 1 2 2
Let me try this.
And I have:
root@letux:~# amixer get "Headset Power Mode" Simple mixer control 'Headset Power Mode',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~# amixer get "PLL Selection" Simple mixer control 'PLL Selection',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~#
Is this ok?
Anyways, setting both to low power/performance has no audible effect.
The HPPLL will give more accurate internal clocks so audio will be more precise and the headset High performance mode gives better dynamic range, it might or might not audible, but I believe with the correct material - not mp3 ;) - there is a difference.
BR and thanks, Nikolaus
Regards, Peter
Peter Ujfalusi (3): mfd: twl6040: Handle mclk (for HPPLL) via clock API ASoC: twl6040: Select LPPLL during standby ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040
Tero Kristo (1): ARM: omap5: add support for fref_xtal_ck
Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++---- drivers/clk/ti/clk-54xx.c | 1 + drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/clk/ti.h | 1 + include/linux/mfd/twl6040.h | 3 ++- sound/soc/codecs/twl6040.c | 12 ++++++---- 10 files changed, 86 insertions(+), 19 deletions(-)
-- 2.8.2
On 05/11/16 10:53, Peter Ujfalusi wrote:
Sometimes I get a data block of random noise... But that might be DMA/interrupt related buffer-underrun, although I do not see any significant messages. Or sox/play has a bug.
Have been playing 4 channel wav with aplay for about an hour and I have not experienced any noise (via line-out + headset), so not sure what could cause it.
In my experiments, playing music is done by sox/play:
play somefile.mp3 remix 1 1 2 2
Let me try this.
now playing some mp3, but I think the sox parameters should be:
play somefile.mp3 remix 1 2 1 2
so the stereo input will be stereo on the headset (ch1-2) and on the handsfree (ch3-4)
Am 11.05.2016 um 10:24 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
On 05/11/16 10:53, Peter Ujfalusi wrote:
Sometimes I get a data block of random noise... But that might be DMA/interrupt related buffer-underrun, although I do not see any significant messages. Or sox/play has a bug.
Have been playing 4 channel wav with aplay for about an hour and I have not experienced any noise (via line-out + headset), so not sure what could cause it.
In my experiments, playing music is done by sox/play:
play somefile.mp3 remix 1 1 2 2
Let me try this.
now playing some mp3, but I think the sox parameters should be:
play somefile.mp3 remix 1 2 1 2
Ah, yes you are right!
so the stereo input will be stereo on the headset (ch1-2) and on the handsfree (ch3-4)
Now it sounds even better and like real stereo :)
BR and thanks, Nikolaus
Hi Peter,
Am 11.05.2016 um 09:53 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
On 05/10/16 16:29, H. Nikolaus Schaller wrote:
Hi Peter,
Am 10.05.2016 um 11:11 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
Hi,
I only send this to the kernel@pyra-handheld.com for testing. Tero's patch for sure needs to be split up for upstream and needs commit message
As for the rest: I think both the mfd and ASoC patch can go upstream if the tesing goes fine.
Some notes: the MCLK for HPPLL is going to be handled runtime and it is only enabled when it has been requested - during audio playback/capture when no audio is running we switch back to LPPLL. According to the datasheet it provides a bit lower power consumption.
The switch between the LPPLL and HPPLL is not possible during active audio, the mixer change will take efect after audio stop and restart. No change in this.
Tested on top of: next-20160509
I have integrated your patches and they appear to work :)
I can check with "devmem2 0x4AE0CDB4" that it changes the ckobuffer from 0x0 to 0x10000000 and back. So this part works fine :)
Great, thanks! I will prepare the patches for upstream for the twl6040.
On the headset port I get what I regard as "good quality" (audiophiles may disagree...).
Yeah, twl6040 is not that bad in this regards IMHO.
The handsfree speakers have big distortion (scrachy, clipped). It did have this before as well but I have the impression that it even got worse. I remember our first experiments with the Pandaboard where it did work (I have to set it up again for comparisons).
Hrm, but this is unrelated to this series, right?
Probably yes. I just noticed that it got even worse with the new patches compared to my patch.
So I wonder what else they are doing except enabling the ckobuffer (which my patch also did).
Too high gain for the HF path?
Well, I notice it audibly at any handsfree level above ca. 20% ().
I can not test HF on OMAP5,
yes, HF it is not available on the omap5evm interface connectors.
But I have built an adapter and speaker setup today for the PandaBoard which has one of the HF channels on a jumper. So I can at least check mono HF.
only the line-out and that sounds OK. Since the Line-out is the same audio signal w/o going through the HF drivers it might be a good idea to see if that also have distortion. If not than the path from HF drivers to the speaker is the one which adds the distortion. Most likely.
The result on the Pandaboard is that it is also distorted, but much less. And it appears that it the scrachy effect is partially coming from the speakers driven to the end of the membrane. I can really see the membrane go in and out at very low frequencies.
Well, this is an effect of the capless Class D amplifier... Other amplifiers would have capacitors with some high-pass effect so that there is no high amplitude at lowest frequencies or DC at all.
But there is still a big difference between PandaBoard and our OMAP5 board. Maybe we really have a HW problem with the twl6040 hookup. There was already one pcb layout bug which was fixed - but either the twl6040 was damaged (and not replaced) or there is another issue (e.g. not enough decoupling capacitor near the twl6040 power rails).
But I can also compare with the PandaBoard schematics.
Sometimes I get a data block of random noise... But that might be DMA/interrupt related buffer-underrun, although I do not see any significant messages. Or sox/play has a bug.
Have been playing 4 channel wav with aplay for about an hour and I have not experienced any noise (via line-out + headset), so not sure what could cause it.
Could be the potential hardware problem I mentioned. For example at high energy situations the twl6040 could draw too much current and the DPLL is thrown out of sync. Or something like that.
Or it is a bug in sox. But unlikely because excactly the same mp3 file plays well on the PandaBoard.
In my experiments, playing music is done by sox/play:
play somefile.mp3 remix 1 1 2 2
Let me try this.
It is just a trick to get two-channel sound played. I think it would be possible to store the remix result in another file and then simply aplay it.
And I have:
root@letux:~# amixer get "Headset Power Mode" Simple mixer control 'Headset Power Mode',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~# amixer get "PLL Selection" Simple mixer control 'PLL Selection',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~#
Is this ok?
Anyways, setting both to low power/performance has no audible effect.
The HPPLL will give more accurate internal clocks so audio will be more precise and the headset High performance mode gives better dynamic range, it might or might not audible, but I believe with the correct material - not mp3 ;) - there is a difference.
Ok, something for the audiophiles to evaluate :) My job is to make it work at all...
BR and thanks, Nikolaus
BR and thanks, Nikolaus
Regards, Peter
Peter Ujfalusi (3): mfd: twl6040: Handle mclk (for HPPLL) via clock API ASoC: twl6040: Select LPPLL during standby ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040
Tero Kristo (1): ARM: omap5: add support for fref_xtal_ck
Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++---- drivers/clk/ti/clk-54xx.c | 1 + drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/clk/ti.h | 1 + include/linux/mfd/twl6040.h | 3 ++- sound/soc/codecs/twl6040.c | 12 ++++++---- 10 files changed, 86 insertions(+), 19 deletions(-)
-- 2.8.2
-- Péter
On 05/11/2016 07:03 PM, H. Nikolaus Schaller wrote:
The handsfree speakers have big distortion (scrachy, clipped). It did have this before as well but I have the impression that it even got worse. I remember our first experiments with the Pandaboard where it did work (I have to set it up again for comparisons).
Hrm, but this is unrelated to this series, right?
Probably yes. I just noticed that it got even worse with the new patches compared to my patch.
So I wonder what else they are doing except enabling the ckobuffer (which my patch also did).
You have distortion when using HPPLL or LPPLL? In both case or only with the HPPLL?
If only with HPPLL, can you try to clk_prepare_enable(twl6040->mclk_clk); right when we get the clock at probe time? Can it be that the HPPLL is not locking because the clock from ckobuffer is not stable yet? If enabling the clock at module probe time helps, then we can try to add delay after enabling the mclk_clk. Optionally we can read the OMAP5 TRM/DM on the ckobuffer timing ;) as last resort, obviously, hehe. I'll check it tomorrow, but it is strange that I don't hear the distortion on the headset or AUX output (omap5-uevm)...
Too high gain for the HF path?
Well, I notice it audibly at any handsfree level above ca. 20% ().
Only handsfree, not on headset?
I can not test HF on OMAP5,
yes, HF it is not available on the omap5evm interface connectors.
But I have built an adapter and speaker setup today for the PandaBoard which has one of the HF channels on a jumper. So I can at least check mono HF.
I remember that, I have omap4-blaze, which have speakers. I might be able to check if it still boots, but again, it is OMAP4.
only the line-out and that sounds OK. Since the Line-out is the same audio signal w/o going through the HF drivers it might be a good idea to see if that also have distortion. If not than the path from HF drivers to the speaker is the one which adds the distortion. Most likely.
The result on the Pandaboard is that it is also distorted, but much less. And it appears that it the scrachy effect is partially coming from the speakers driven to the end of the membrane. I can really see the membrane go in and out at very low frequencies.
Well, this is an effect of the capless Class D amplifier... Other amplifiers would have capacitors with some high-pass effect so that there is no high amplitude at lowest frequencies or DC at all.
On Galaxy Nexus there is zero distortion on the handsfree, so the HW is capable, not sure what we are missing. Galaxy Nexus uses AESS/ABE for audio, but can not recall if this has anything to do with distortion free HF.
But there is still a big difference between PandaBoard and our OMAP5 board. Maybe we really have a HW problem with the twl6040 hookup. There was already one pcb layout bug which was fixed - but either the twl6040 was damaged (and not replaced) or there is another issue (e.g. not enough decoupling capacitor near the twl6040 power rails).
But I can also compare with the PandaBoard schematics.
Probably the omap4-evm (Blaze) schematics will give some hints on how the HF is connected there.
Sometimes I get a data block of random noise... But that might be DMA/interrupt related buffer-underrun, although I do not see any significant messages. Or sox/play has a bug.
Have been playing 4 channel wav with aplay for about an hour and I have not experienced any noise (via line-out + headset), so not sure what could cause it.
Could be the potential hardware problem I mentioned. For example at high energy situations the twl6040 could draw too much current and the DPLL is thrown out of sync. Or something like that.
Or it is a bug in sox. But unlikely because excactly the same mp3 file plays well on the PandaBoard.
sox is good, I was playing mp3 with it for another hour, but did not noticed any noise, distortion. One thing I noticed is that if I give the 'repeat -' parameter to it to loop the song, I will have underruns in ALSA, without the repeat no underruns :o
In my experiments, playing music is done by sox/play:
play somefile.mp3 remix 1 1 2 2
Let me try this.
It is just a trick to get two-channel sound played. I think it would be possible to store the remix result in another file and then simply aplay it.
And I have:
root@letux:~# amixer get "Headset Power Mode" Simple mixer control 'Headset Power Mode',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~# amixer get "PLL Selection" Simple mixer control 'PLL Selection',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~#
Is this ok?
Anyways, setting both to low power/performance has no audible effect.
The HPPLL will give more accurate internal clocks so audio will be more precise and the headset High performance mode gives better dynamic range, it might or might not audible, but I believe with the correct material - not mp3 ;) - there is a difference.
Ok, something for the audiophiles to evaluate :) My job is to make it work at all...
BR and thanks, Nikolaus
BR and thanks, Nikolaus
Regards, Peter ---- Peter Ujfalusi (3): mfd: twl6040: Handle mclk (for HPPLL) via clock API ASoC: twl6040: Select LPPLL during standby ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040
Tero Kristo (1): ARM: omap5: add support for fref_xtal_ck
Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++---- drivers/clk/ti/clk-54xx.c | 1 + drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/clk/ti.h | 1 + include/linux/mfd/twl6040.h | 3 ++- sound/soc/codecs/twl6040.c | 12 ++++++---- 10 files changed, 86 insertions(+), 19 deletions(-)
-- 2.8.2
-- Péter
Hi Peter,
Am 11.05.2016 um 21:06 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
On 05/11/2016 07:03 PM, H. Nikolaus Schaller wrote:
The handsfree speakers have big distortion (scrachy, clipped). It did have this before as well but I have the impression that it even got worse. I remember our first experiments with the Pandaboard where it did work (I have to set it up again for comparisons).
Hrm, but this is unrelated to this series, right?
Probably yes. I just noticed that it got even worse with the new patches compared to my patch.
So I wonder what else they are doing except enabling the ckobuffer (which my patch also did).
You have distortion when using HPPLL or LPPLL? In both case or only with the HPPLL?
I have not noticed any difference yet.
If only with HPPLL, can you try to clk_prepare_enable(twl6040->mclk_clk); right when we get the clock at probe time? Can it be that the HPPLL is not locking because the clock from ckobuffer is not stable yet? If enabling the clock at module probe time helps, then we can try to add delay after enabling the mclk_clk. Optionally we can read the OMAP5 TRM/DM on the ckobuffer timing ;) as last resort, obviously, hehe.
Well, If I remember correctly it just turns on the output buffer. So it starts "immediately".
Yes, you are right that the HPPLL needs some time to lock.
I'll check it tomorrow, but it is strange that I don't hear the distortion on the headset or AUX output (omap5-uevm)...
I have not checked with another Pyra board with speakers. Just with oscilloscope and no speakers. There I see a nice rectangular signal which duty cycle seems to change depending on the music. So I can "see" the PWM.
Too high gain for the HF path?
Well, I notice it audibly at any handsfree level above ca. 20% ().
Only handsfree, not on headset?
It is on handsfree only. Except the white noise bursts.
And it seems to be a mix of two phenomena. One is more a mechanical with the membrane and the other with driver signals or software.
I can not test HF on OMAP5,
yes, HF it is not available on the omap5evm interface connectors.
But I have built an adapter and speaker setup today for the PandaBoard which has one of the HF channels on a jumper. So I can at least check mono HF.
I remember that, I have omap4-blaze, which have speakers. I might be able to check if it still boots, but again, it is OMAP4.
Looks as if we are the first project to have handsfree twl6040 on omap5 :)
Ah, wasn't there some erratum about offset compensation? So if the amplifier has a significant DC offset, it drives the membrane to the mechanical end and therefore can move only in one direction which gives a highly distorted sound?
only the line-out and that sounds OK. Since the Line-out is the same audio signal w/o going through the HF drivers it might be a good idea to see if that also have distortion. If not than the path from HF drivers to the speaker is the one which adds the distortion. Most likely.
The result on the Pandaboard is that it is also distorted, but much less. And it appears that it the scrachy effect is partially coming from the speakers driven to the end of the membrane. I can really see the membrane go in and out at very low frequencies.
Well, this is an effect of the capless Class D amplifier... Other amplifiers would have capacitors with some high-pass effect so that there is no high amplitude at lowest frequencies or DC at all.
On Galaxy Nexus there is zero distortion on the handsfree, so the HW is capable, not sure what we are missing. Galaxy Nexus uses AESS/ABE for audio, but can not recall if this has anything to do with distortion free HF.
But there is still a big difference between PandaBoard and our OMAP5 board. Maybe we really have a HW problem with the twl6040 hookup. There was already one pcb layout bug which was fixed - but either the twl6040 was damaged (and not replaced) or there is another issue (e.g. not enough decoupling capacitor near the twl6040 power rails).
But I can also compare with the PandaBoard schematics.
Probably the omap4-evm (Blaze) schematics will give some hints on how the HF is connected there.
Ah, good to know for cross-check as well.
Sometimes I get a data block of random noise... But that might be DMA/interrupt related buffer-underrun, although I do not see any significant messages. Or sox/play has a bug.
Have been playing 4 channel wav with aplay for about an hour and I have not experienced any noise (via line-out + headset), so not sure what could cause it.
Could be the potential hardware problem I mentioned. For example at high energy situations the twl6040 could draw too much current and the DPLL is thrown out of sync. Or something like that.
Or it is a bug in sox. But unlikely because excactly the same mp3 file plays well on the PandaBoard.
sox is good, I was playing mp3 with it for another hour, but did not noticed any noise, distortion. One thing I noticed is that if I give the 'repeat -' parameter to it to loop the song, I will have underruns in ALSA, without the repeat no underruns :o
In my experiments, playing music is done by sox/play:
play somefile.mp3 remix 1 1 2 2
Let me try this.
It is just a trick to get two-channel sound played. I think it would be possible to store the remix result in another file and then simply aplay it.
And I have:
root@letux:~# amixer get "Headset Power Mode" Simple mixer control 'Headset Power Mode',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~# amixer get "PLL Selection" Simple mixer control 'PLL Selection',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~#
Is this ok?
Anyways, setting both to low power/performance has no audible effect.
The HPPLL will give more accurate internal clocks so audio will be more precise and the headset High performance mode gives better dynamic range, it might or might not audible, but I believe with the correct material - not mp3 ;) - there is a difference.
Ok, something for the audiophiles to evaluate :) My job is to make it work at all...
BR and thanks, Nikolaus
BR and thanks, Nikolaus
Regards, Peter ---- Peter Ujfalusi (3): mfd: twl6040: Handle mclk (for HPPLL) via clock API ASoC: twl6040: Select LPPLL during standby ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040
Tero Kristo (1): ARM: omap5: add support for fref_xtal_ck
Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++---- drivers/clk/ti/clk-54xx.c | 1 + drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/clk/ti.h | 1 + include/linux/mfd/twl6040.h | 3 ++- sound/soc/codecs/twl6040.c | 12 ++++++---- 10 files changed, 86 insertions(+), 19 deletions(-)
-- 2.8.2
-- Péter
-- Péter
BR and thanks, Nikolaus
Hi all, I have done a test on a different Pyra board:
* there I have no stereo (i.e. one channel is dead) * no scratch and noise bursts - so that might be a completely unrelated issue of the test board I have used first * the clipping is still present at higher volume - this indeed sounds like mechanical noise from the speakers running into the stop block... If I mentally try to ignore this sound component the music sounds good and crisp and high quality.
Summary: some of the problems are related to the specific unit I have tested so far (the whole OMAP5 runs a little less stable - maybe our 19MHz XTAL is instable?). Another problem is with the D-class amplifier making the speaker membrane run into full deflection.
BR, Nikolaus
-
H. Nikolaus Schaller -
Peter Ujfalusi