[PATCHv6][ 3/5] video: mx3fb: Introduce regulator support.
Denis Carikli
denis at eukrea.com
Wed Feb 26 06:40:54 EST 2014
On 02/26/2014 11:20 AM, Alexander Shiyan wrote:
> Why you want to use an excess "regulator-name" property?
I'll fix that.
>> + /* In dt mode,
>> + * using devm_regulator_get would require that the proprety referencing
>> + * the regulator phandle has to be inside the mx3fb node.
>
> What???
[...]
> Just use devm_regulator_get(dev, "lcd") for both dt/non-dt case.
About the use of devm_regulator_get instead of regulator_get:
There is a "dma ipu driver" for the mx3* at drivers/dma/ipu/ipu_idmac.c
This framebuffer driver (mx3fb) uses that "dma ipu driver".
In non-dt mode("board files"), this framebuffer driver requires some
platform data which has resource informations about the ipu.
So to get device tree bindings support for the mx3fb driver, at first I
exported the "dma ipu driver" as DMA bindings, to be used in the dts,
and then made the mx3fb driver use that.
The comment[1] to that patchset was to instead have similar bindings
that looks like the IPUv3 ones(IPUv3 is a staging drm driver), and not
to export the "dma ipu driver" bindings to the dts.
So I made the bindings look like that:
display0: display at di0 {
[...]
display-timings {
[...]
};
};
ipu: ipu at 53fc0000 {
compatible = "fsl,imx35-ipu";
reg = <0x53fc0000 0x4000>;
clocks = <&clks 55>;
display = <&display0>;
};
So that is very similar to the imx-drm binding[2].
To achieve that, I've set the .compatible property of the mx3fb driver
to "fsl,<chip>-ipu", so it would look like the IPUv3 bindings, and then
I handled the "dma ipu driver" registration in a way that doesn't export
it to the dts.
The difference is that the imx-drm driver has separate drivers for
handling each display type(parallel display, tve, lvds and HDMI) while
the mx3fb doesn't.
using devm_regulator_get(NULL, "lcd") would result in a crash, because
of devres_add.
using devm_regulator_get(dev, "lcd") would be better but it would
instead mean that the regulator handle will have to be a child of the
mx3fb's ipu node (ipu at 53fc0000).
That's because devm_regulator_get will end calling of_get_regulator
(trough _regulator_get, and regulator_dev_lookup), which will in turn
lookup that regulator in the childs of dev->of_node.
That's why I want to pass it a NULL instead of a device struct, and I
can't do it in devm_regulator_get because of devres_add, so I ended up
using regulator_get directly.
References.
-----------
[1]http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/205846.html
[2]Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
Denis.
More information about the linux-arm-kernel
mailing list