On Tue, Sep 22, 2009 at 03:42:37PM -0600, Miguel Aguilar wrote:
> Mark Brown wrote:
> > On Tue, Sep 22, 2009 at 01:28:58PM -0600, miguel.aguilar@xxxxxxxxxxxx wrote:
> > The code is OK but the driver isn't using DAPM.
> [MA] Should it use DAPM, if so, How is the proper way to do that?
Depends if there's any meaningful power management - if there is then
most of the other drivers have examples of what to do, you basically
tell the core about all the things you have power switches for and how
they're interconnected then it will power on only the bits that are in
active use at any one moment.
It's not essential, though - my comment was more there because the
comments in the driver mentioned that power management was being done by
DAPM when it isn't currently.
> >> +static int cq93vc_probe(struct platform_device *pdev)
> >> +{
> > You should make the driver a regular platform device - that way you
> > won't need to do the trick with the global variable to get the resources
> > and you won't need to register the DAIs on module_init. See wm8350 for
> > an example of doing this with a platform device.
> I tried that and I got many some Virtual memory errors since there is
> the VCIF and the CQ0093 codecs belong to the same register domain of
> the DM365, the first driver which is being registered is the CQ0093
> before the VCIF, but the VCIF is the one that enables the common clock
> for both, so that's why I get the virtual memory error. I'll take a
> look into wm8350 code and I'll try to make it a platform device.
Sounds like you want to make a MFD for the block as a whole and then
have the CODEC and CPU parts of it as subdevices of that. drivers/mfd
provides a lightweight framework for doing this.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
