On Thursday 30 May 2013, Tomi Valkeinen wrote:

  On 30/05/13 14:12, Jean-Christophe PLAGNIOL-VILLARD wrote:

quoted

On 12:34 Thu 30 May     , Tomi Valkeinen wrote:

quoted

On some platforms DPI requires a regulator to be enabled to power up the
output pins. This regulator is, for some reason, currently attached to
the virtual omapdss device, instead of the DPI device. This does not
work for DT, as the regulator mappings need to be described in the DT
data, and the virtual omapdss device is not present there.

Fix the issue by acquiring the regulator in the DPI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to DPI.

as discuss with Arnd we should handle regular enable and disable at device
probe for every device as we do for pinctrl

I'm not sure what you mean. Enable of what? The regulator? Why would we
enable it in the device's probe, as the device may never even be used?

It's an idea I had a while ago, but not yet discussed in the open.

Jean-Christophe just posted patches to move the mapping of interrupt numbers
into platform_drv_probe(), just before calling the driver ->probe() callback,
and we already have similar code to set up the default pinctrl state of
a device before calling probe().

This can be extended to further subsystems, but that has to be done
carefully to avoid regressions. Ideally we would move a lot of boilerplate
code out of the driver specific ->probe() function into common code.
Possible candidates for this include:

* calling devm_request_mem_region for the "reg" property
* calling devm_ioremap on the "reg" property"
* calling devm_gpio_request for all gpio lines
* calling devm_regulator_get on all regulators
* calling devm_reset_control_get on all reset lines
* calling devm_dma_request_slave_channel on all dma channels
* calling devm_of_pwm_get for all pwm channels
* ...

For most of these (maybe all), I think we need some form of opt-in
model on the driver side because there are cases where aquiring some
of these resources is not mandatory, and it only works if the driver
is using DT probing.

IF we want to do this, it also needs a lot of thought, and we shouldn't
do it carelessly. We might also need some extra infrastructure in revres
to simplify access to the resources we got from the OF node.

The irq resources are particularly trivial because we already claim
them in of_platform_populate, so moving that to platform_drv_probe()
is straightforward and solves existing bugs without creating a huge
regression potential, but it's harder for the others.

	Arnd