linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).