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.
next prev parent reply other threads:[~2014-02-26 11:40 UTC|newest]
Thread overview: 7+ 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 ` [PATCHv6][ 2/5] video: mx3fb: Add device tree suport Denis Carikli
2014-02-26 9:59 ` [PATCHv6][ 3/5] video: mx3fb: Introduce regulator support Denis Carikli
2014-02-26 10:20 ` [PATCHv6][ 3/5] video: mx3fb: Introduce r =?UTF-8?B?ZWd1bGF0b3Igc3Vwc Alexander Shiyan
2014-02-26 11:40 ` Denis Carikli [this message]
2014-02-26 9:59 ` [PATCHv6][ 4/5] ARM: dts: i.MX35: Add display support Denis Carikli
2014-02-26 9:59 ` [PATCHv6][ 5/5] ARM: dts: mbimxsd35 Add video and displays support 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).