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