audio initialization fails due to TWL6040
Quoted 3 lines · Tobias Jakobi
And another one!
Maybe Peter can take a look at this one?
FYI, Peter, only slightly related to this, but can you also please unravel the mcbsp and sidetone .dtsi entries to be separate devices? I'm hoping to deprecate ti,hwmods for v3.15 and use the compatible property instead, so we need to have 1-to-1 mapping of devices defined in the .dtsi files compared to the real hardware devices mapped in the omap_hwmod_*_data.c files.
There's some more info regarding that in thread:
http://www.spinics.net/lists/arm-kernel/msg288036.html
Regards,
Tony
Hi Tony,
I have missed this mail...
Quoted 6 lines · Tony Lindgren
Quoted 3 lines · Tobias Jakobi
And another one!
Maybe Peter can take a look at this one?
It has been already fixed (bug in the arch/arm/mm/dma-mapping.c)
Quoted 10 lines
FYI, Peter, only slightly related to this, but can you also please unravel the mcbsp and sidetone .dtsi entries to be separate devices? I'm hoping to deprecate ti,hwmods for v3.15 and use the compatible property instead, so we need to have 1-to-1 mapping of devices defined in the .dtsi files compared to the real hardware devices mapped in the omap_hwmod_*_data.c files.
There's some more info regarding that in thread:
How urgent this is?
Due to a 'hw feature' around the sidetone this is not as straight forward as it sounds...
I can put this to my to do list.
Signature · 5 lines
Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 21 lines · Peter Ujfalusi
Hi Tony,
I have missed this mail...
Quoted 6 lines · Tony Lindgren
Quoted 3 lines · Tobias Jakobi
And another one!
Maybe Peter can take a look at this one?
It has been already fixed (bug in the
arch/arm/mm/dma-mapping.c)Quoted 7 lines
FYI, Peter, only slightly related to this, but can you also please unravel the mcbsp and sidetone .dtsi entries to be separate devices? I'm hoping to deprecate ti,hwmods for v3.15 and use the compatible property instead, so we need to have 1-to-1 mapping of devices defined in the .dtsi files compared to the real hardware devices mapped in the omap_hwmod_*_data.c files.
Quoted 5 lines
Quoted 3 lines
There's some more info regarding that in thread:
How urgent this is?
Well we cannot sanely deprecate the "ti,hwmods" and move on to matching hwmod data with DT data based on the compatible flag. So it's a bit of a blocker for v3.15 or so time frame.
Quoted 2 lines
Due to a 'hw feature' around the sidetone this is not as straight forward as it sounds...
OK. The driver(s) should still be able to coordinate things to sort it out hopefully?
Quoted 1 line
I can put this to my to do list.
Thanks.
Regards,
Tony
Quoted 9 lines · Tony Lindgren
Well we cannot sanely deprecate the "ti,hwmods" and move on to matching hwmod data with DT data based on the compatible flag. So it's a bit of a blocker for v3.15 or so time frame.
Quoted 2 lines
Due to a 'hw feature' around the sidetone this is not as straight forward as it sounds...
OK. The driver(s) should still be able to coordinate things to sort it out hopefully?
After a quick look at the code:
- sidetone _is_ broken when we boot with DT for sure already.
- sidetone works only if we boot in legacy mode.
While it is true that ST block has it's own address space and even dedicated irq line, but..
ST can be enabled from the McBSP address space (via SSELCR_REG). When ST is enabled we need to disable the corresponding McBSP's autoidle. The reason for this is that the ST block is clocked from the McBSP IP's interface clock. If the interface clock of the McBSP is idling there will be glitches in the sidetone generation due to not having continuously running clock for it's internals.
For legacy boot we had this handled by a custom callback to disable autoidle for the McBSP when the ST starts and enable it back when ST is stopped:
arch/arm/mach-omap2/mcbsp.c:omap3_enable_st_clock() is the callback we call.
Normal audio will work via McBSP if we get rid of hwmod, the driver can load and operate that way. As for the sidetone functionality: it is broken when we boot with DT and the removal of hwmod will have no effect on this.
The Sidetone address space also have sysconfig register with AUTOIDLE bit, but it has no effect on the McBSP_ICLK autoidle itself.
In theory we can handle the sidetone as we do right now, but we need one
thing: an API so drivers can disable/enable autoidle of an already enabled clock.
CCing Tero for this, he might have pointers or idea on how we can do this.
Signature · 5 lines
Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 15 lines · Peter Ujfalusi
Quoted 9 lines · Tony Lindgren
Well we cannot sanely deprecate the "ti,hwmods" and move on to matching hwmod data with DT data based on the compatible flag. So it's a bit of a blocker for v3.15 or so time frame.
Quoted 2 lines
Due to a 'hw feature' around the sidetone this is not as straight forward as it sounds...
OK. The driver(s) should still be able to coordinate things to sort it out hopefully?
After a quick look at the code:
- sidetone _is_ broken when we boot with DT for sure already.
- sidetone works only if we boot in legacy mode.
Quoted 8 lines
While it is true that ST block has it's own address space and even dedicated irq line, but..
ST can be enabled from the McBSP address space (viaSSELCR_REG). When ST is enabled we need to disable the corresponding McBSP's autoidle. The reason for this is that the ST block is clocked from the McBSP IP's interface clock. If the interface clock of the McBSP is idling there will be glitches in the sidetone generation due to not having continuously running clock for it's internals.
It seems that this you may be able to sort out just by exporting a function from the ST code for the McBSP to call, and for the autoidle, can't you..
Quoted 3 lines
For legacy boot we had this handled by a custom callback to disable autoidle for the McBSP when the ST starts and enable it back when ST is stopped:
arch/arm/mach-omap2/mcbsp.c:omap3_enable_st_clock() is the callback we call.
..just use runtime PM calls from the ST module?
Quoted 3 lines
Normal audio will work via McBSP if we get rid of hwmod, the driver can load and operate that way. As for the sidetone functionality: it is broken when we boot with DT and the removal of hwmod will have no effect on this.
OK
Quoted 2 lines
The Sidetone address space also have sysconfig register with AUTOIDLE bit, but it has no effect on the
McBSP_ICLKautoidle itself.
Yes that's because they're separate hardware modules like we have them in the hwmod code :)
Quoted 4 lines
In theory we can handle the sidetone as we do right now, but we need one
thing: an API so drivers can disable/enable autoidle of an already enabled clock.CCing Tero for this, he might have pointers or idea on how we can do this.
It seems that runtime PM should be able to do that. But maybe I'm missing something here.
Regards,
Tony