[pandaboard] audio initialization fails due to TWL6040

[pandaboard] audio initialization fails due to TWL6040

[Tobias Jakobi]

And another one!

https://bugzilla.kernel.org/show_bug.cgi?id=66451

- Tobias

Re: [pandaboard] audio initialization fails due to TWL6040

[Tony Lindgren]

* Tobias Jakobi <tjakobi@math.uni-bielefeld.de> [131203 14:45]:
> And another one!
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=66451

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

Re: [pandaboard] audio initialization fails due to TWL6040

[Peter Ujfalusi]

Hi Tony,

I have missed this mail...

On 12/05/2013 08:53 PM, Tony Lindgren wrote:
> * Tobias Jakobi <tjakobi@math.uni-bielefeld.de> [131203 14:45]:
>> And another one!
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=66451
> 
> Maybe Peter can take a look at this one?

It has been already fixed (bug in the arch/arm/mm/dma-mapping.c)

> 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

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.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [pandaboard] audio initialization fails due to TWL6040

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [131229 23:36]:
> Hi Tony,
> 
> I have missed this mail...
> 
> On 12/05/2013 08:53 PM, Tony Lindgren wrote:
> > * Tobias Jakobi <tjakobi@math.uni-bielefeld.de> [131203 14:45]:
> >> And another one!
> >>
> >> https://bugzilla.kernel.org/show_bug.cgi?id=66451
> > 
> > Maybe Peter can take a look at this one?
> 
> It has been already fixed (bug in the arch/arm/mm/dma-mapping.c)
> 
> > 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
> 
> 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.

> 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?

> I can put this to my to do list.

Thanks.

Regards,

Tony

Re: [pandaboard] audio initialization fails due to TWL6040

[Peter Ujfalusi]

On 01/08/2014 12:53 AM, Tony Lindgren wrote:
> 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.
>
>> 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.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [pandaboard] audio initialization fails due to TWL6040

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [140108 05:25]:
> On 01/08/2014 12:53 AM, Tony Lindgren wrote:
> > 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.
> >
> >> 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.

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..
 
> 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?
 
> 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
 
> The Sidetone address space also have sysconfig register with AUTOIDLE bit, but
> it has no effect on the McBSP_ICLK autoidle itself.

Yes that's because they're separate hardware modules like we have them in
the hwmod code :)

> 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