All of lore.kernel.org
 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.

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.

  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.