[PATCH v2 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone

[Peter Ujfalusi]

On 04/19/2016 02:51 AM, Tony Lindgren wrote:
>>> Then all these modules just sit on the L4 interconnet at
>>> separate targets, including the clockdomain.
>>
>> The McBSPi core and it's sidetone is in the same clock domain as the sidetone
>> is using the McBSPi interface clock. It is kind of a leech ;)
> 
> Well they still are able to use the McBSP interface clock independently
> AFAIK :)

After trying to hunt down documentation (which I'm still in the process):
Initially the sidetone was designed to be built inside of the MCBSPLP ip found
in OMAP3, but at some point it has been decided to attach the sidetone from
the outside and make wire up the connection like it is ended up in OMAP3.
I have not found reasoning, but if I can guess they wanted to avoid three
different McBSPLP modules in OMAP3:
type1: McBSP1,4,5 - MCBSPLP with 128 FIFO
type2: McBSP2 - MCBSPLP + 1024+256 FIFO + sidetone
type3: McBSP3 - MCBSPLP + 128 FIFO + sidetone

Also the sidetone is never used again in OMAP4/5 so it made the integration
and errata (if any) fixes easier for the upcoming SoCs.
But it is just a guess.

>From the documents it is also clear that McBSPLP.sidetone is using the
McBSPLP's ICLK, but what is not explained in the TRM is that there are
internal clocks going from McBSP to sidetone for the data bus between them.
The iclk is needed so the core can kind of run independently from the clocks
coming from McBSPLP (for data exchange between the two modules).
If McBSP is not configured these clocks are not running which renders the
sidetone non operational.

I can send a cut down series to fix the current sidetone hwmod (main_clk and
prevent it to look at the PRCM bit) plus reworking the pdata callback so we
can support both legacy and DT boot.

-- 
Péter