[alsa-devel] [PATCH v2 2/2] ASoC: omap-mcpdm: Replace legacy driver

Péter Ujfalusi peter.ujfalusi at ti.com
Tue Aug 23 08:49:44 CEST 2011


On Monday 22 August 2011 15:39:15 Lars-Peter Clausen wrote:
> omap_mcpdm_widgets is a global variable.

Yeah, as most of the snd_soc_dapm_widget.

> You assign to it in asoc_mcpdm_probe

Since at compile time I don't have the pointer for the mcpdm (it is allocated 
earlier in the same function), I need to assign it somewhere.

> and read from it in omap_mcpdm_add_dapm_widget.

I don't see any reference to the omap_mcpdm_widgets in there.

> The fact that you hide your *mcpdm in a void pointer doesn't make it less
> hackish.

Well, from that point of view most of the kernel is hackish. We tend to have 
void pointers for various things, like platform_data, device_data, 
driver_data, private_data, etc.
You see, the point here is that this private_data for the widget can be used 
for others as well, if needed. It would make no sense to put "struct 
omap_mcpdm *mcpdm", just because I have this requirement first, does it? 

For sure, I could have chosen to create one global pointer for this event 
handler:

static struct omap_mcpdm *mcpdm_global;

Use the mcpdm_global within omap_mcpdm_interface_event function, and assign it 
at asoc_mcpdm_probe time.

Would that look better? IMHO it is not.

As Mark suggested, we should have accessor for this, if we are going to have 
such a thing.

The reason for this (as I described in the commit message):
OMAP McPDM has the requirement (along with the twl6040), that we need to stop 
the cpu dai _after_ the DAC/ADC has been stopped on the codec side.
Now, I do not want to hard wire the twl6040, nor the omap-mcpdm with each 
other.
The omap-mcpdm implements the event callback, and the machine driver is 
responsible to create the DAPM route to make sure we follow the correct 
sequence.
I could as well implemented these things in the machine driver (+global 
pointer for mcpdm), but that can lead duplicated code in the future (new 
machine driver, etc).

-- 
Péter


More information about the Alsa-devel mailing list