From: Denis Carikli <denis@eukrea.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv6][ 3/5] video: mx3fb: Introduce regulator support.
Date: Wed, 26 Feb 2014 11:40:54 +0000 [thread overview]
Message-ID: <530DD2C6.1060108@eukrea.com> (raw)
In-Reply-To: <1393410030.488354633@f216.i.mail.ru>
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@di0 {
[...]
display-timings {
[...]
};
};
ipu: ipu@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@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.
WARNING: multiple messages have this Message-ID (diff)
From: denis@eukrea.com (Denis Carikli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv6][ 3/5] video: mx3fb: Introduce regulator support.
Date: Wed, 26 Feb 2014 12:40:54 +0100 [thread overview]
Message-ID: <530DD2C6.1060108@eukrea.com> (raw)
In-Reply-To: <1393410030.488354633@f216.i.mail.ru>
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.
next prev parent reply other threads:[~2014-02-26 11:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-26 9:59 [PATCHv6][ 1/5] video: mx3fb: Use devm_kzalloc Denis Carikli
2014-02-26 9:59 ` Denis Carikli
2014-02-26 9:59 ` [PATCHv6][ 2/5] video: mx3fb: Add device tree suport Denis Carikli
2014-02-26 9:59 ` Denis Carikli
2014-02-26 9:59 ` [PATCHv6][ 3/5] video: mx3fb: Introduce regulator support Denis Carikli
2014-02-26 9:59 ` Denis Carikli
2014-02-26 10:20 ` [PATCHv6][ 3/5] video: mx3fb: Introduce r =?UTF-8?B?ZWd1bGF0b3Igc3Vwc Alexander Shiyan
2014-02-26 10:20 ` [PATCHv6][ 3/5] video: mx3fb: Introduce regulator support Alexander Shiyan
2014-02-26 11:40 ` Denis Carikli [this message]
2014-02-26 11:40 ` Denis Carikli
2014-02-26 9:59 ` [PATCHv6][ 4/5] ARM: dts: i.MX35: Add display support Denis Carikli
2014-02-26 9:59 ` Denis Carikli
2014-02-26 9:59 ` [PATCHv6][ 5/5] ARM: dts: mbimxsd35 Add video and displays support Denis Carikli
2014-02-26 9:59 ` Denis Carikli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530DD2C6.1060108@eukrea.com \
--to=denis@eukrea.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.