[alsa-devel] [PATCH V1 2/3] ASoC: fsl_spdif: spba clk is needed by spdif device

[Shengjiu Wang]

On Sat, Oct 10, 2015 at 01:35:57PM -0700, Nicolin Chen wrote:
> On Sat, Oct 10, 2015 at 05:03:07PM -0300, Fabio Estevam wrote:
> > On Sat, Oct 10, 2015 at 7:26 AM, Shengjiu Wang
> > <shengjiu.wang at freescale.com> wrote:
> > 
> > > I think spba clock should be used by the audio IP not DMA, because in same
> > > situation the FSL_SSI doesn't need this clock.
> > 
> > According to this commit from FSL BSP, the SSI2 port on MX53 is
> > connected to SPBA and needs the SPBA clock:
> > 
> > http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/arch/arm/mach-mx5/clock.c?h=imx_2.6.35_maintain&id=2438f48431b7aff00a522502d5a6ea217ea133d9
> 
> Hmm, the detail of an SPBA issue is sometimes complicated due to
> different fabric designs between SoCs. We cannot simply say that
> a DMA access for an IP under the Shared Peripheral Bus requires
> SPBA clock or not unless the hardware team clearly demands that.
> 
> However, as an arbiter, the SPBA must be outside any of those IPs
> and tied to the SDMA in order to balancing memory access between
> the SDMA and a co-existing CPU. The question is whether we treat
> it as a part of an IP wrapper or a part of the SDMA.
> 
> Therefore, unless a CPU access would fail even *without any SDMA
> access being launched*, it sounds fair to me to put it into the
> DMA code.

I discussed this issue with IC team. The SPBA bus has 3 master port,
one is for SDMA, one is for MCU (ARM core), the third one is for DSP (
currently there is no connection for DSP). Any two master port are used
simultaneously, there will be arbitration issue when SPBA clock is not
enabled.

So I think it is better put SPBA clock in Audio IP, because if there is
DSP master port + MCU master used, there will be issue too. (DSP master 
port is not used in i.MX chip). Anyway I think put it in SDMA driver is
not good choice, if SDMA is removed, there will be still issue. Put it
in Audio IP maybe more safe.