On Wed, Jan 5, 2011 at 6:01 PM, Nori, Sekhar <[email protected]> wrote:

> Hi Subhasish,
>
> On Wed, Jan 05, 2011 at 14:48:00, S.Ghosh wrote:
> >       >
> >       > +static struct clk mcasp_pru_clk = {
> >       > +     .name           = "mcasp_pru",
> >       > +     .parent         = &pll0_sysclk2,
> >       > +     .lpsc           = DA8XX_LPSC1_McASP0,
> >       > +     .gpsc           = 1,
> >       > +     .flags          = DA850_CLK_ASYNC3,
> >       > +};
> >
> >
> >       There is already a mcasp clock defined. Why not use it instead
> > of
> >       replicating it with a different name? Not doing so will cause a
> > mess
> >       with reference counting.
> >
> >
> >
> > [SG] -- This McASP clock is bound with the McASP driver by the device
> > ID. This device ID (davinci-mcasp.0) is not
> > available to the SUART driver.
>
> You can also look up the clock using con_id if not dev_id. Duplicating
> clock structure is definitely wrong.
>

[SG] -- The con_id for the default McASP CLK entry is marked as NULL.
           Hence that cannot be used directly.

>
> > Moreover, the McASP driver is written
> > specifically for Audio applications. These API's
> > are not suitable for our purposes. Hence, to enable the SUART we disable
> > the sound sub-system completely and
> > configured the McASP in the SUART API's.
>
> Relying on audio driver to be disabled is not a good solution
> either. What if there are two McASPs on an SoC and you want to
> use one for audio and the other as UART?
>

[SG] -- DA850 atleast, is having only one McASP, as for DA830, we relied
           on Kconfig to select the McASP to be used, but that's not
finalized yet.

>
> I think this is tending toward the need for a common McASP API
> which both UART and audio drivers can use. That should take care
> of the clock conundrum too.
>

[SG] -- For now using clk_add_alias as suggested by Kelvin.
           And yes, I believe any low level driver should be kept
independent
          of specific applications. But, there might be other reasons like
throughput penalty etc,
          for which another layer of abstraction was exempted for the McASP
driver.
          Not sure though, just imagining.


>
> Thanks,
> Sekhar
>
>
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to