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@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/...
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.