On 05/11/2012 11:34 PM, Mark Brown wrote:
The issue is the tastefulness. Just looking at the binding it's immediately clear that the only thing that the extra levels of indirection are adding is the removal of the mfd_add_cells() call from the MFD driver which isn't particularly helping anything and is basically Linux specific.
It is not really a coincident that we have the drivers structured in a way they are at the moment (with or without MFD). We have several functionality provided by this chip (twl6040). In one chip it provides audio (twl6040-codec), vibra (twl6040-vibra) and we are going to have few more additions as well (GPO, clock driver to provide the McPDM functional clock).
We might see more integrated solution in a future which would combine the current pmic and the audio in a single chip. If this happens we can just use the dts sections describing the functionalities of the twl6040 appended to this - theoretical - chip. The child (or drivers for the functionality) only needs small update for compatible_of, and new chip access wrapper. In this case the core chip driver (twl6040 MFD) will no longer exist/make sense since the functionality provided by the twl6040 chip has been merged together with the PMIC.
You might be right that the resulting dts section for the chip is just represents the current MD stack, but if I want to prepare for the future this is the way I think is the best for us.