On Sat, Nov 07, 2009 at 12:31:43PM +0900, jassi brar wrote: > Well, since the abstraction(dev-audio) is supposed to be common for > I2S, PCM and AC97 protocol, we need to have another layer which > communicate protocol specific platform data. > This pdata is meant to serve that purpose in future. There's no real abstraction here - it's just a place to put the devices and whatnot for the various audio related devices. I would be very surprised to ever see any need for generic audio platform data, the devices don't have that much in common. > > I'd just embed the GPIO configuration callback in a driver-specific > > platform data. > If not for pdata, the cfg_gpio wudn't be enough for future SoCs which > not only configure the MUX'ed pins but also set the drive strength. Some > might also need configuring the SoC which may not fall into either Clock > or Power domain. > So, if I am to remove pdata, maybe cfg_gpio can be renamed config_controller? I'd be happier if it stayed as GPIO - that'd still cover things like drive strength. This is because the platform device code has recently gained the ability to provide platform specific annotations on the device itself which would allow this to be done in a way that is transparent to the edge drivers and avoids code duplication in all the device drivers. This is (IIRC) used by the OMAP power domain management and I'd expect that the Samsung SoCs will end up going down a similar way in future. I'd rather try to reduce the amount of device specific handling for things like that which appears. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
