* Re: [PATCH] video: ARM CLCD: Remove duplicated include in amba-clcd.c
From: Pawel Moll @ 2014-11-17 11:07 UTC (permalink / raw)
To: Qiang Chen
Cc: tomi.valkeinen@ti.com, plagnioj@jcrosoft.com,
linux@arm.linux.org.uk, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, qcwj.lk@gmail.com
In-Reply-To: <1416216301-15854-1-git-send-email-qiang2.chen@sonymobile.com>
On Mon, 2014-11-17 at 09:25 +0000, Qiang Chen wrote:
> This patch fixes duplicated include dma-mapping.h in
> drivers/video/fbdev/amba-clcd.c
>
> Signed-off-by: Qiang Chen <qiang2.chen@sonymobile.com>
> ---
> drivers/video/fbdev/amba-clcd.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
> index 6ad23bd..32c0b6b 100644
> --- a/drivers/video/fbdev/amba-clcd.c
> +++ b/drivers/video/fbdev/amba-clcd.c
> @@ -27,7 +27,6 @@
> #include <linux/bitops.h>
> #include <linux/clk.h>
> #include <linux/hardirq.h>
> -#include <linux/dma-mapping.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/of_graph.h>
Acked-by: Pawel Moll <pawel.moll@arm.com>
Thanks!
Pawel
^ permalink raw reply
* [PATCH 0/2] dt-bindings: simplefb: Drop the advice about using a specific path for nodes
From: Hans de Goede @ 2014-11-17 11:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
Review of the u-boot sunxi simplefb patches has lead to the decision that
u-boot should not use a specific path to find the nodes as this goes contrary
to how devicetree usually works.
Instead a platform specific compatible + properties should be used for this.
This series updates the simplefb bindings reflect this.
Regards,
Hans
^ permalink raw reply
* [PATCH 1/2] dt-bindings: simplefb: Drop the advice about using a specific path for nodes
From: Hans de Goede @ 2014-11-17 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416224086-5698-1-git-send-email-hdegoede@redhat.com>
This goes contrary to how devicetree usually works, so drop it. Instead if
the firmware needs to be able to find a specific node it should use a
platform specific compatible + properties for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index f8fb7e6..4474ef6 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -31,12 +31,10 @@ enable them. This way if e.g. later on support for more display clocks get
added, the simplefb nodes will already contain this info and the firmware
does not need to be updated.
-If pre-filled framebuffer nodes are used, they should be named
-"framebuffer#-<output>", e.g. "framebuffer0-hdmi". The output should be
-included in the name since different outputs typically require different
-clocks and the clocks are part of the pre-populated nodes. The firmware must
-rename the nodes to the standard "framebuffer@<address>" name using the
-runtime chosen address when enabling the nodes.
+If pre-filled framebuffer nodes are used, the firmware may need extra
+information to find the right node. In that case an extra platform specific
+compatible and platform specific properties should be used and documented,
+see e.g. simple-framebuffer-sunxi.txt .
Required properties:
- compatible: "simple-framebuffer"
--
2.1.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Hans de Goede @ 2014-11-17 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416224086-5698-1-git-send-email-hdegoede@redhat.com>
If pre-filled framebuffer nodes are used, the firmware may need extra
properties to find the right node. This documents the properties to use
for this on sunxi platforms.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
.../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
new file mode 100644
index 0000000..84ca264
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
@@ -0,0 +1,33 @@
+Sunxi specific Simple Framebuffer bindings
+
+This binding documents sunxi specific extensions to the simple-framebuffer
+bindings. The sunxi simplefb u-boot code relies on the devicetree containing
+pre-populated simplefb nodes.
+
+These extensions are intended so that u-boot can select the right node based
+on which pipeline and output is being used. As such they are solely intended
+for firmware / bootloader use, and the OS should ignore them.
+
+Required properties:
+- compatible: "sunxi,framebuffer"
+- sunxi,pipeline:
+ <0> for the de_be0 -> lcdc0 -> output pipeline
+ <1> for the de_be1 -> lcdc1 -> output pipeline
+- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
+
+Example:
+
+chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@0 {
+ compatible = "sunxi,framebuffer", "simple-framebuffer";
+ sunxi,pipeline = <0>;
+ sunxi,output = "hdmi";
+ clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
+ <&ahb_gates 44>;
+ status = "disabled";
+ };
+};
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Grant Likely @ 2014-11-17 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416224086-5698-3-git-send-email-hdegoede@redhat.com>
On Mon, Nov 17, 2014 at 11:34 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> If pre-filled framebuffer nodes are used, the firmware may need extra
> properties to find the right node. This documents the properties to use
> for this on sunxi platforms.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
> ---
> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> new file mode 100644
> index 0000000..84ca264
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> @@ -0,0 +1,33 @@
> +Sunxi specific Simple Framebuffer bindings
> +
> +This binding documents sunxi specific extensions to the simple-framebuffer
> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
> +pre-populated simplefb nodes.
> +
> +These extensions are intended so that u-boot can select the right node based
> +on which pipeline and output is being used. As such they are solely intended
> +for firmware / bootloader use, and the OS should ignore them.
> +
> +Required properties:
> +- compatible: "sunxi,framebuffer"
> +- sunxi,pipeline:
> + <0> for the de_be0 -> lcdc0 -> output pipeline
> + <1> for the de_be1 -> lcdc1 -> output pipeline
> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
> +
> +Example:
> +
> +chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + framebuffer@0 {
> + compatible = "sunxi,framebuffer", "simple-framebuffer";
> + sunxi,pipeline = <0>;
> + sunxi,output = "hdmi";
> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
> + <&ahb_gates 44>;
> + status = "disabled";
> + };
> +};
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: simplefb: Drop the advice about using a specific path for nodes
From: Grant Likely @ 2014-11-17 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416224086-5698-2-git-send-email-hdegoede@redhat.com>
On Mon, Nov 17, 2014 at 11:34 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> This goes contrary to how devicetree usually works, so drop it. Instead if
> the firmware needs to be able to find a specific node it should use a
> platform specific compatible + properties for this.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
> ---
> Documentation/devicetree/bindings/video/simple-framebuffer.txt | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> index f8fb7e6..4474ef6 100644
> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -31,12 +31,10 @@ enable them. This way if e.g. later on support for more display clocks get
> added, the simplefb nodes will already contain this info and the firmware
> does not need to be updated.
>
> -If pre-filled framebuffer nodes are used, they should be named
> -"framebuffer#-<output>", e.g. "framebuffer0-hdmi". The output should be
> -included in the name since different outputs typically require different
> -clocks and the clocks are part of the pre-populated nodes. The firmware must
> -rename the nodes to the standard "framebuffer@<address>" name using the
> -runtime chosen address when enabling the nodes.
> +If pre-filled framebuffer nodes are used, the firmware may need extra
> +information to find the right node. In that case an extra platform specific
> +compatible and platform specific properties should be used and documented,
> +see e.g. simple-framebuffer-sunxi.txt .
>
> Required properties:
> - compatible: "simple-framebuffer"
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Ian Campbell @ 2014-11-17 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416224086-5698-3-git-send-email-hdegoede@redhat.com>
On Mon, 2014-11-17 at 12:34 +0100, Hans de Goede wrote:
> +- sunxi,pipeline:
> + <0> for the de_be0 -> lcdc0 -> output pipeline
> + <1> for the de_be1 -> lcdc1 -> output pipeline
Can we express this as a more descriptive string rather than a number,
to better handle future developments?
Otherwise both patches in this series look good to me.
> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
> +
> +Example:
> +
> +chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + framebuffer@0 {
> + compatible = "sunxi,framebuffer", "simple-framebuffer";
> + sunxi,pipeline = <0>;
> + sunxi,output = "hdmi";
> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
> + <&ahb_gates 44>;
> + status = "disabled";
> + };
> +};
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Maxime Ripard @ 2014-11-17 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416224086-5698-3-git-send-email-hdegoede@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]
On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
> If pre-filled framebuffer nodes are used, the firmware may need extra
> properties to find the right node. This documents the properties to use
> for this on sunxi platforms.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> new file mode 100644
> index 0000000..84ca264
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> @@ -0,0 +1,33 @@
> +Sunxi specific Simple Framebuffer bindings
> +
> +This binding documents sunxi specific extensions to the simple-framebuffer
> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
> +pre-populated simplefb nodes.
> +
> +These extensions are intended so that u-boot can select the right node based
> +on which pipeline and output is being used. As such they are solely intended
> +for firmware / bootloader use, and the OS should ignore them.
> +
> +Required properties:
> +- compatible: "sunxi,framebuffer"
> +- sunxi,pipeline:
> + <0> for the de_be0 -> lcdc0 -> output pipeline
> + <1> for the de_be1 -> lcdc1 -> output pipeline
> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
> +
> +Example:
> +
> +chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + framebuffer@0 {
> + compatible = "sunxi,framebuffer", "simple-framebuffer";
> + sunxi,pipeline = <0>;
> + sunxi,output = "hdmi";
> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
> + <&ahb_gates 44>;
If we're going that way, then maybe having to specify clock-names
would be better in order to know which clock is what?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Hans de Goede @ 2014-11-17 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141117124721.GQ6414@lukather>
Hi,
On 11/17/2014 01:47 PM, Maxime Ripard wrote:
> On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
>> If pre-filled framebuffer nodes are used, the firmware may need extra
>> properties to find the right node. This documents the properties to use
>> for this on sunxi platforms.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>> new file mode 100644
>> index 0000000..84ca264
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>> @@ -0,0 +1,33 @@
>> +Sunxi specific Simple Framebuffer bindings
>> +
>> +This binding documents sunxi specific extensions to the simple-framebuffer
>> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
>> +pre-populated simplefb nodes.
>> +
>> +These extensions are intended so that u-boot can select the right node based
>> +on which pipeline and output is being used. As such they are solely intended
>> +for firmware / bootloader use, and the OS should ignore them.
>> +
>> +Required properties:
>> +- compatible: "sunxi,framebuffer"
>> +- sunxi,pipeline:
>> + <0> for the de_be0 -> lcdc0 -> output pipeline
>> + <1> for the de_be1 -> lcdc1 -> output pipeline
>> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
>> +
>> +Example:
>> +
>> +chosen {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + framebuffer@0 {
>> + compatible = "sunxi,framebuffer", "simple-framebuffer";
>> + sunxi,pipeline = <0>;
>> + sunxi,output = "hdmi";
>> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
>> + <&ahb_gates 44>;
>
> If we're going that way, then maybe having to specify clock-names
> would be better in order to know which clock is what?
I agree that using clock-names is more human readable then phandle's,
but that is simply not how clocks are specified anywhere in dt.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Grant Likely @ 2014-11-17 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141117124721.GQ6414@lukather>
On Mon, Nov 17, 2014 at 12:47 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
>> If pre-filled framebuffer nodes are used, the firmware may need extra
>> properties to find the right node. This documents the properties to use
>> for this on sunxi platforms.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>> new file mode 100644
>> index 0000000..84ca264
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>> @@ -0,0 +1,33 @@
>> +Sunxi specific Simple Framebuffer bindings
>> +
>> +This binding documents sunxi specific extensions to the simple-framebuffer
>> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
>> +pre-populated simplefb nodes.
>> +
>> +These extensions are intended so that u-boot can select the right node based
>> +on which pipeline and output is being used. As such they are solely intended
>> +for firmware / bootloader use, and the OS should ignore them.
>> +
>> +Required properties:
>> +- compatible: "sunxi,framebuffer"
>> +- sunxi,pipeline:
>> + <0> for the de_be0 -> lcdc0 -> output pipeline
>> + <1> for the de_be1 -> lcdc1 -> output pipeline
>> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
>> +
>> +Example:
>> +
>> +chosen {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + framebuffer@0 {
>> + compatible = "sunxi,framebuffer", "simple-framebuffer";
>> + sunxi,pipeline = <0>;
>> + sunxi,output = "hdmi";
>> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
>> + <&ahb_gates 44>;
>
> If we're going that way, then maybe having to specify clock-names
> would be better in order to know which clock is what?
I wouldn't go that way with this binding since the driver has no need
to differentiate between the clocks, and driver authors shouldn't be
encouraged to do so. The purpose of the clocks in this node is only
for itemizing dependencies, not for how to configure the clocks.
Firmware shouldn't care at all about the clocks list, it only needs to
find the correct pre-populated node to fill in and enable.
g.
^ permalink raw reply
* Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
From: Vladimir Zapolskiy @ 2014-11-17 15:12 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen
In-Reply-To: <54661A30.3010708@ti.com>
Hi Jyri,
On 14.11.2014 17:05, Jyri Sarha wrote:
> On 11/14/2014 04:37 PM, Vladimir Zapolskiy wrote:
>> Hi Jyri,
>>
>> On 12.11.2014 16:41, Jyri Sarha wrote:
>>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>>> ---
>>> drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
>>> index a6e08ff..6d129f2 100644
>>> --- a/drivers/video/fbdev/omap2/dss/hdmi.h
>>> +++ b/drivers/video/fbdev/omap2/dss/hdmi.h
>>> @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
>>> struct hdmi_audio_format *aud_fmt);
>>> void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp,
>>> struct hdmi_audio_dma *aud_dma);
>>> -static inline bool hdmi_mode_has_audio(int mode)
>>> +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg)
>>> {
>>> - return mode = HDMI_HDMI ? true : false;
>>> + return cfg->hdmi_dvi_mode = HDMI_HDMI ? true : false;
>>> }
>>>
>>> /* HDMI DRV data */
>>>
>>
>> would it be possible for you to rearrange the changes preserving the
>> following sequence?
>>
>> 1) 13/19
>> 2) 15/19
>> 3) 11/19
>> 4) 14/19
>> 5) 16/19
>>
>
> Sure, I can do that. Everything should be fine in that order too.
>
>> Otherwise I'm worried that someone's git rebase may fail.
>>
sorry again, I meant git-bisect, git rebase is fine.
> But do not follow why. Did you notice that 10/19 removes the config
> options that enable the pieces of code that are deleted in 13/19 and
> 15/19. IOW, the code that uses hdmi_mode_has_audio() (and would become
> broken by 11/19) is already disabled by 10/19. Git-wise I see no problem
> either.
Right, I was worried by changed hdmi_mode_has_audio() API and still
present source code, which uses the old API (it is fixed in the
following patches). If the code that uses hdmi_mode_has_audio() is
disabled by 10/19 and the kernel can be successfully compiled and
working on partial application of the changeset, then there should be no
problem with git-bisect, and probably no need to rearrange the commits.
> I'll rearrange the patches if you still insist there is a problem with
> current order, but I would like to understand why.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v2 0/2] dt-bindings: simplefb: Drop the advice about using a specific path for nodes
From: Hans de Goede @ 2014-11-17 15:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomi,
Here is v2 of my patch set to slightly tweak the simplefb bindings wrt
the interface between the boot-loader and the devicetree for pre-populated
simplefb nodes.
Changes in v2: Changed the simplefb-sunxi bindings to use a single
sunxi,pipeline string property instead of a sunxi,pipeline int and a
sunxi,output string property.
This patch set is all acked up, and a fix to the binding changes you've
already queued for 3.19, so please queue these 2 patches for 3.19.
Thanks & Regards,
Hans
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: simplefb: Drop the advice about using a specific path for nodes
From: Hans de Goede @ 2014-11-17 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416238625-28590-1-git-send-email-hdegoede@redhat.com>
This goes contrary to how devicetree usually works, so drop it. Instead if
the firmware needs to be able to find a specific node it should use a
platform specific compatible + properties for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
---
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index f8fb7e6..4474ef6 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -31,12 +31,10 @@ enable them. This way if e.g. later on support for more display clocks get
added, the simplefb nodes will already contain this info and the firmware
does not need to be updated.
-If pre-filled framebuffer nodes are used, they should be named
-"framebuffer#-<output>", e.g. "framebuffer0-hdmi". The output should be
-included in the name since different outputs typically require different
-clocks and the clocks are part of the pre-populated nodes. The firmware must
-rename the nodes to the standard "framebuffer@<address>" name using the
-runtime chosen address when enabling the nodes.
+If pre-filled framebuffer nodes are used, the firmware may need extra
+information to find the right node. In that case an extra platform specific
+compatible and platform specific properties should be used and documented,
+see e.g. simple-framebuffer-sunxi.txt .
Required properties:
- compatible: "simple-framebuffer"
--
2.1.0
^ permalink raw reply related
* [PATCH v2 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Hans de Goede @ 2014-11-17 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416238625-28590-1-git-send-email-hdegoede@redhat.com>
If pre-filled framebuffer nodes are used, the firmware may need extra
properties to find the right node. This documents the properties to use
for this on sunxi platforms.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
---
.../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
new file mode 100644
index 0000000..4188606
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
@@ -0,0 +1,33 @@
+Sunxi specific Simple Framebuffer bindings
+
+This binding documents sunxi specific extensions to the simple-framebuffer
+bindings. The sunxi simplefb u-boot code relies on the devicetree containing
+pre-populated simplefb nodes.
+
+These extensions are intended so that u-boot can select the right node based
+on which pipeline is being used. As such they are solely intended for
+firmware / bootloader use, and the OS should ignore them.
+
+Required properties:
+- compatible: "sunxi,framebuffer"
+- sunxi,pipeline, one of:
+ "de_be0-lcd0"
+ "de_be1-lcd1"
+ "de_be0-lcd0-hdmi"
+ "de_be1-lcd1-hdmi"
+
+Example:
+
+chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@0 {
+ compatible = "sunxi,framebuffer", "simple-framebuffer";
+ sunxi,pipeline = "de_be0-lcd0-hdmi";
+ clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
+ <&ahb_gates 44>;
+ status = "disabled";
+ };
+};
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Maxime Ripard @ 2014-11-17 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6vqiC08sP+o3bduGfvUdwRtHm8+_7EdZccJjS86qVKvxQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]
On Mon, Nov 17, 2014 at 01:39:18PM +0000, Grant Likely wrote:
> On Mon, Nov 17, 2014 at 12:47 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
> >> If pre-filled framebuffer nodes are used, the firmware may need extra
> >> properties to find the right node. This documents the properties to use
> >> for this on sunxi platforms.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >> ---
> >> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
> >> 1 file changed, 33 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> >> new file mode 100644
> >> index 0000000..84ca264
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> >> @@ -0,0 +1,33 @@
> >> +Sunxi specific Simple Framebuffer bindings
> >> +
> >> +This binding documents sunxi specific extensions to the simple-framebuffer
> >> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
> >> +pre-populated simplefb nodes.
> >> +
> >> +These extensions are intended so that u-boot can select the right node based
> >> +on which pipeline and output is being used. As such they are solely intended
> >> +for firmware / bootloader use, and the OS should ignore them.
> >> +
> >> +Required properties:
> >> +- compatible: "sunxi,framebuffer"
> >> +- sunxi,pipeline:
> >> + <0> for the de_be0 -> lcdc0 -> output pipeline
> >> + <1> for the de_be1 -> lcdc1 -> output pipeline
> >> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
> >> +
> >> +Example:
> >> +
> >> +chosen {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + ranges;
> >> +
> >> + framebuffer@0 {
> >> + compatible = "sunxi,framebuffer", "simple-framebuffer";
> >> + sunxi,pipeline = <0>;
> >> + sunxi,output = "hdmi";
> >> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
> >> + <&ahb_gates 44>;
> >
> > If we're going that way, then maybe having to specify clock-names
> > would be better in order to know which clock is what?
>
> I wouldn't go that way with this binding since the driver has no need
> to differentiate between the clocks, and driver authors shouldn't be
> encouraged to do so. The purpose of the clocks in this node is only
> for itemizing dependencies, not for how to configure the clocks.
> Firmware shouldn't care at all about the clocks list, it only needs to
> find the correct pre-populated node to fill in and enable.
Well, if we want to play the "DT as an ABI" stuff, you have no
guarantee that in the future, simplefb will still be the driver bound
to "sunxi,framebuffer", and that this driver doesn't need to
differentiate which clocks it needs to protect and which are not
needed. Especially with the combination of the output that you now
hardcode.
Of course, if now we don't care at all about this ABI thing, it's
completely fine for me. But I'll archive this email preciously.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Hans de Goede @ 2014-11-18 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141117155514.GU6414@lukather>
Hi,
On 11/17/2014 04:55 PM, Maxime Ripard wrote:
> On Mon, Nov 17, 2014 at 01:39:18PM +0000, Grant Likely wrote:
>> On Mon, Nov 17, 2014 at 12:47 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>>> On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
>>>> If pre-filled framebuffer nodes are used, the firmware may need extra
>>>> properties to find the right node. This documents the properties to use
>>>> for this on sunxi platforms.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>> ---
>>>> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
>>>> 1 file changed, 33 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>>> new file mode 100644
>>>> index 0000000..84ca264
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>>> @@ -0,0 +1,33 @@
>>>> +Sunxi specific Simple Framebuffer bindings
>>>> +
>>>> +This binding documents sunxi specific extensions to the simple-framebuffer
>>>> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
>>>> +pre-populated simplefb nodes.
>>>> +
>>>> +These extensions are intended so that u-boot can select the right node based
>>>> +on which pipeline and output is being used. As such they are solely intended
>>>> +for firmware / bootloader use, and the OS should ignore them.
>>>> +
>>>> +Required properties:
>>>> +- compatible: "sunxi,framebuffer"
>>>> +- sunxi,pipeline:
>>>> + <0> for the de_be0 -> lcdc0 -> output pipeline
>>>> + <1> for the de_be1 -> lcdc1 -> output pipeline
>>>> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
>>>> +
>>>> +Example:
>>>> +
>>>> +chosen {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + ranges;
>>>> +
>>>> + framebuffer@0 {
>>>> + compatible = "sunxi,framebuffer", "simple-framebuffer";
>>>> + sunxi,pipeline = <0>;
>>>> + sunxi,output = "hdmi";
>>>> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
>>>> + <&ahb_gates 44>;
>>>
>>> If we're going that way, then maybe having to specify clock-names
>>> would be better in order to know which clock is what?
>>
>> I wouldn't go that way with this binding since the driver has no need
>> to differentiate between the clocks, and driver authors shouldn't be
>> encouraged to do so. The purpose of the clocks in this node is only
>> for itemizing dependencies, not for how to configure the clocks.
>> Firmware shouldn't care at all about the clocks list, it only needs to
>> find the correct pre-populated node to fill in and enable.
>
> Well, if we want to play the "DT as an ABI" stuff, you have no
> guarantee that in the future, simplefb will still be the driver bound
> to "sunxi,framebuffer"
Huh? We do have that guarantee, or at least that a simplefb bindings
compatible driver is, the "sunxi,framebuffer" bindings live in:
Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
With the filename already being a big hint, further more it states that:
"This binding documents sunxi specific extensions to the simple-framebuffer
bindings. The sunxi simplefb u-boot code relies on the devicetree containing
pre-populated simplefb nodes.
These extensions are intended so that u-boot can select the right node based
on which pipeline is being used. As such they are solely intended for
firmware / bootloader use, and the OS should ignore them."
Which to me seems to guarantee that we're talking about a simple-framebuffer
compatible node here. The scope of these extensions are very narrow, there
only purpose is to allow the bootloader to find the right pre-populated simplefb
node, everything else is specified by the simplefb bindings, not these
extensions.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Ian Campbell @ 2014-11-18 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <546B0026.2010107@redhat.com>
On Tue, 2014-11-18 at 09:15 +0100, Hans de Goede wrote:
> Hi,
>
> On 11/17/2014 04:55 PM, Maxime Ripard wrote:
> > On Mon, Nov 17, 2014 at 01:39:18PM +0000, Grant Likely wrote:
> >> On Mon, Nov 17, 2014 at 12:47 PM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >>> On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
> >>>> If pre-filled framebuffer nodes are used, the firmware may need extra
> >>>> properties to find the right node. This documents the properties to use
> >>>> for this on sunxi platforms.
> >>>>
> >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>>> ---
> >>>> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
> >>>> 1 file changed, 33 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> >>>> new file mode 100644
> >>>> index 0000000..84ca264
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> >>>> @@ -0,0 +1,33 @@
> >>>> +Sunxi specific Simple Framebuffer bindings
> >>>> +
> >>>> +This binding documents sunxi specific extensions to the simple-framebuffer
> >>>> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
> >>>> +pre-populated simplefb nodes.
> >>>> +
> >>>> +These extensions are intended so that u-boot can select the right node based
> >>>> +on which pipeline and output is being used. As such they are solely intended
> >>>> +for firmware / bootloader use, and the OS should ignore them.
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible: "sunxi,framebuffer"
> >>>> +- sunxi,pipeline:
> >>>> + <0> for the de_be0 -> lcdc0 -> output pipeline
> >>>> + <1> for the de_be1 -> lcdc1 -> output pipeline
> >>>> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
> >>>> +
> >>>> +Example:
> >>>> +
> >>>> +chosen {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <1>;
> >>>> + ranges;
> >>>> +
> >>>> + framebuffer@0 {
> >>>> + compatible = "sunxi,framebuffer", "simple-framebuffer";
> >>>> + sunxi,pipeline = <0>;
> >>>> + sunxi,output = "hdmi";
> >>>> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
> >>>> + <&ahb_gates 44>;
> >>>
> >>> If we're going that way, then maybe having to specify clock-names
> >>> would be better in order to know which clock is what?
> >>
> >> I wouldn't go that way with this binding since the driver has no need
> >> to differentiate between the clocks, and driver authors shouldn't be
> >> encouraged to do so. The purpose of the clocks in this node is only
> >> for itemizing dependencies, not for how to configure the clocks.
> >> Firmware shouldn't care at all about the clocks list, it only needs to
> >> find the correct pre-populated node to fill in and enable.
> >
> > Well, if we want to play the "DT as an ABI" stuff, you have no
> > guarantee that in the future, simplefb will still be the driver bound
> > to "sunxi,framebuffer"
>
> Huh? We do have that guarantee, or at least that a simplefb bindings
> compatible driver is, the "sunxi,framebuffer" bindings live in:
>
> Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>
> With the filename already being a big hint, further more it states that:
>
> "This binding documents sunxi specific extensions to the simple-framebuffer
> bindings. The sunxi simplefb u-boot code relies on the devicetree containing
> pre-populated simplefb nodes.
>
> These extensions are intended so that u-boot can select the right node based
> on which pipeline is being used. As such they are solely intended for
> firmware / bootloader use, and the OS should ignore them."
There may be an argument here for using the slightly redundant compat
string "allwinner,simple-framebuffer" in order to reinforce that this is
an extension to simple-framebuffer, as opposed to a binding for a
completely separate "non-simple" sunxi framebuffer driver which I think
is what Maxime may be imagining.
Alternatively (or as well) perhaps these extension should be a series of
extensions (one per platform) described in "appendices" of the main
simple-framebuffer.txt. I know Grant expressed a preference for a
separate document though and I think just using the more expressive name
above would be sufficient, but thought I'd mention it as a possible
option.
Ian.
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Hans de Goede @ 2014-11-18 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416300438.25454.40.camel@hellion.org.uk>
Hi,
On 11/18/2014 09:47 AM, Ian Campbell wrote:
> On Tue, 2014-11-18 at 09:15 +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/17/2014 04:55 PM, Maxime Ripard wrote:
>>> On Mon, Nov 17, 2014 at 01:39:18PM +0000, Grant Likely wrote:
>>>> On Mon, Nov 17, 2014 at 12:47 PM, Maxime Ripard
>>>> <maxime.ripard@free-electrons.com> wrote:
>>>>> On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
>>>>>> If pre-filled framebuffer nodes are used, the firmware may need extra
>>>>>> properties to find the right node. This documents the properties to use
>>>>>> for this on sunxi platforms.
>>>>>>
>>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>>>> ---
>>>>>> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
>>>>>> 1 file changed, 33 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..84ca264
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>>>>> @@ -0,0 +1,33 @@
>>>>>> +Sunxi specific Simple Framebuffer bindings
>>>>>> +
>>>>>> +This binding documents sunxi specific extensions to the simple-framebuffer
>>>>>> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
>>>>>> +pre-populated simplefb nodes.
>>>>>> +
>>>>>> +These extensions are intended so that u-boot can select the right node based
>>>>>> +on which pipeline and output is being used. As such they are solely intended
>>>>>> +for firmware / bootloader use, and the OS should ignore them.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible: "sunxi,framebuffer"
>>>>>> +- sunxi,pipeline:
>>>>>> + <0> for the de_be0 -> lcdc0 -> output pipeline
>>>>>> + <1> for the de_be1 -> lcdc1 -> output pipeline
>>>>>> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
>>>>>> +
>>>>>> +Example:
>>>>>> +
>>>>>> +chosen {
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <1>;
>>>>>> + ranges;
>>>>>> +
>>>>>> + framebuffer@0 {
>>>>>> + compatible = "sunxi,framebuffer", "simple-framebuffer";
>>>>>> + sunxi,pipeline = <0>;
>>>>>> + sunxi,output = "hdmi";
>>>>>> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
>>>>>> + <&ahb_gates 44>;
>>>>>
>>>>> If we're going that way, then maybe having to specify clock-names
>>>>> would be better in order to know which clock is what?
>>>>
>>>> I wouldn't go that way with this binding since the driver has no need
>>>> to differentiate between the clocks, and driver authors shouldn't be
>>>> encouraged to do so. The purpose of the clocks in this node is only
>>>> for itemizing dependencies, not for how to configure the clocks.
>>>> Firmware shouldn't care at all about the clocks list, it only needs to
>>>> find the correct pre-populated node to fill in and enable.
>>>
>>> Well, if we want to play the "DT as an ABI" stuff, you have no
>>> guarantee that in the future, simplefb will still be the driver bound
>>> to "sunxi,framebuffer"
>>
>> Huh? We do have that guarantee, or at least that a simplefb bindings
>> compatible driver is, the "sunxi,framebuffer" bindings live in:
>>
>> Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>
>> With the filename already being a big hint, further more it states that:
>>
>> "This binding documents sunxi specific extensions to the simple-framebuffer
>> bindings. The sunxi simplefb u-boot code relies on the devicetree containing
>> pre-populated simplefb nodes.
>>
>> These extensions are intended so that u-boot can select the right node based
>> on which pipeline is being used. As such they are solely intended for
>> firmware / bootloader use, and the OS should ignore them."
>
> There may be an argument here for using the slightly redundant compat
> string "allwinner,simple-framebuffer" in order to reinforce that this is
> an extension to simple-framebuffer, as opposed to a binding for a
> completely separate "non-simple" sunxi framebuffer driver which I think
> is what Maxime may be imagining.
>
> Alternatively (or as well) perhaps these extension should be a series of
> extensions (one per platform) described in "appendices" of the main
> simple-framebuffer.txt. I know Grant expressed a preference for a
> separate document though and I think just using the more expressive name
> above would be sufficient, but thought I'd mention it as a possible
> option.
That is a good suggestion, as discussed on irc, lets go with that.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Maxime Ripard @ 2014-11-18 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <546B0026.2010107@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4765 bytes --]
On Tue, Nov 18, 2014 at 09:15:34AM +0100, Hans de Goede wrote:
> Hi,
>
> On 11/17/2014 04:55 PM, Maxime Ripard wrote:
> > On Mon, Nov 17, 2014 at 01:39:18PM +0000, Grant Likely wrote:
> >> On Mon, Nov 17, 2014 at 12:47 PM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >>> On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
> >>>> If pre-filled framebuffer nodes are used, the firmware may need extra
> >>>> properties to find the right node. This documents the properties to use
> >>>> for this on sunxi platforms.
> >>>>
> >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>>> ---
> >>>> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
> >>>> 1 file changed, 33 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> >>>> new file mode 100644
> >>>> index 0000000..84ca264
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> >>>> @@ -0,0 +1,33 @@
> >>>> +Sunxi specific Simple Framebuffer bindings
> >>>> +
> >>>> +This binding documents sunxi specific extensions to the simple-framebuffer
> >>>> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
> >>>> +pre-populated simplefb nodes.
> >>>> +
> >>>> +These extensions are intended so that u-boot can select the right node based
> >>>> +on which pipeline and output is being used. As such they are solely intended
> >>>> +for firmware / bootloader use, and the OS should ignore them.
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible: "sunxi,framebuffer"
> >>>> +- sunxi,pipeline:
> >>>> + <0> for the de_be0 -> lcdc0 -> output pipeline
> >>>> + <1> for the de_be1 -> lcdc1 -> output pipeline
> >>>> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
> >>>> +
> >>>> +Example:
> >>>> +
> >>>> +chosen {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <1>;
> >>>> + ranges;
> >>>> +
> >>>> + framebuffer@0 {
> >>>> + compatible = "sunxi,framebuffer", "simple-framebuffer";
> >>>> + sunxi,pipeline = <0>;
> >>>> + sunxi,output = "hdmi";
> >>>> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
> >>>> + <&ahb_gates 44>;
> >>>
> >>> If we're going that way, then maybe having to specify clock-names
> >>> would be better in order to know which clock is what?
> >>
> >> I wouldn't go that way with this binding since the driver has no need
> >> to differentiate between the clocks, and driver authors shouldn't be
> >> encouraged to do so. The purpose of the clocks in this node is only
> >> for itemizing dependencies, not for how to configure the clocks.
> >> Firmware shouldn't care at all about the clocks list, it only needs to
> >> find the correct pre-populated node to fill in and enable.
> >
> > Well, if we want to play the "DT as an ABI" stuff, you have no
> > guarantee that in the future, simplefb will still be the driver bound
> > to "sunxi,framebuffer"
>
> Huh? We do have that guarantee, or at least that a simplefb bindings
> compatible driver is, the "sunxi,framebuffer" bindings live in:
>
> Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>
> With the filename already being a big hint, further more it states that:
Yeah, well, that can change. The compatible itself can't, but we're
free to move around the drivers however we see fit (as long as the
user-space is not impacted)
> "This binding documents sunxi specific extensions to the simple-framebuffer
> bindings. The sunxi simplefb u-boot code relies on the devicetree containing
> pre-populated simplefb nodes.
>
> These extensions are intended so that u-boot can select the right node based
> on which pipeline is being used. As such they are solely intended for
> firmware / bootloader use, and the OS should ignore them."
>
> Which to me seems to guarantee that we're talking about a simple-framebuffer
> compatible node here. The scope of these extensions are very narrow, there
> only purpose is to allow the bootloader to find the right pre-populated simplefb
> node, everything else is specified by the simplefb bindings, not these
> extensions.
My point was that what we might need to know these clocks at some
point in the future. But if you don't believe we will, it's fine for
me.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] simplefb: Change simplefb_init from module_init to fs_initcall
From: Thierry Reding @ 2014-11-18 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXZ4V4GHvyDLOP8FYvPuGArc5G0aO6NCE9FKHT24YRGPg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
On Thu, Nov 13, 2014 at 09:58:41AM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Thu, Nov 13, 2014 at 9:52 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> >> -module_init(simplefb_init);
> >> +/*
> >> + * While this can be a module, if builtin it's most likely the console
> >> + * So let's leave module_exit but move module_init to an earlier place
> >> + */
> >
> > Not really related to this patch itself, but do we want to support
> > simplefb as a module? It seems like it's going to be most of the time
> > broken.
>
> If it depends on clocks, it won't work as a module, as CCF will have disabled
> all unused clocks at that point.
If it does depend on anything beyond clocks it won't work at all. Clocks
are special because they get set up very early at boot time. If it turns
out that a simplefb ever needs a regulator to remain on, and that's even
quite likely to happen eventually, it's going to fail miserably, because
those regulators will typically be provided by a PMIC on an I2C bus. The
regulator won't be registered until very late into the boot process and
a regulator_get() call will almost certainly cause the simplefb driver
to defer probing.
Now deferring probing is a real showstopper for simplefb, because not
only does it make the framebuffer useless as early boot console, once
probing is attempted again the clocks that it would have needed to
acquire to keep going will already have been switched off, too.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] simplefb: Change simplefb_init from module_init to fs_initcall
From: Hans de Goede @ 2014-11-18 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141118101911.GA15769@ulmo>
Hi,
On 11/18/2014 11:19 AM, Thierry Reding wrote:
> On Thu, Nov 13, 2014 at 09:58:41AM +0100, Geert Uytterhoeven wrote:
>> Hi Maxime,
>>
>> On Thu, Nov 13, 2014 at 9:52 AM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>>>> -module_init(simplefb_init);
>>>> +/*
>>>> + * While this can be a module, if builtin it's most likely the console
>>>> + * So let's leave module_exit but move module_init to an earlier place
>>>> + */
>>>
>>> Not really related to this patch itself, but do we want to support
>>> simplefb as a module? It seems like it's going to be most of the time
>>> broken.
>>
>> If it depends on clocks, it won't work as a module, as CCF will have disabled
>> all unused clocks at that point.
>
> If it does depend on anything beyond clocks it won't work at all. Clocks
> are special because they get set up very early at boot time. If it turns
> out that a simplefb ever needs a regulator to remain on, and that's even
> quite likely to happen eventually, it's going to fail miserably, because
> those regulators will typically be provided by a PMIC on an I2C bus. The
> regulator won't be registered until very late into the boot process and
> a regulator_get() call will almost certainly cause the simplefb driver
> to defer probing.
Right, this has been discussed already and the plan is to have simplefb
continue its probe function and return success from it if it encounters
any -eprobe_defer errors, while tracking which resources it misses.
And then have a late_initcall which will claim any resources which failed
with -eprobe beforehand.
> Now deferring probing is a real showstopper for simplefb, because not
> only does it make the framebuffer useless as early boot console, once
> probing is attempted again the clocks that it would have needed to
> acquire to keep going will already have been switched off, too.
That is not true, even with the current implementation, if all necessary
drivers are built in, then simplefb will come up later, but it will still
come up before the late_initcall which disables the clocks.
Once we do the split probing described above (which is something which
we plan to do when it becomes necessary), then simplefb will still come
up early.
Regards,
Hans
^ permalink raw reply
* [PATCH v3 0/2] dt-bindings: simplefb: Drop the advice about using a specific path for nodes
From: Hans de Goede @ 2014-11-18 11:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomi,
So it turns out we needed a v3, as I mistakenly went with "sunxi," as vendor
prefix for the allwinner specific properties, but the registered vendor prefix
for allwinner is "allwinnner,", this version fixes this.
Changes in v3: Use proper "allwinnner," for the compatible string and vendor
specific properties.
Changes in v2: Changed the simplefb-sunxi bindings to use a single
sunxi,pipeline string property instead of a sunxi,pipeline int and a
sunxi,output string property.
This patch set is all acked up, and a fix to the binding changes you've
already queued for 3.19, so please queue these 2 patches for 3.19.
Thanks & Regards,
Hans
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: simplefb: Drop the advice about using a specific path for nodes
From: Hans de Goede @ 2014-11-18 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416309051-26784-1-git-send-email-hdegoede@redhat.com>
This goes contrary to how devicetree usually works, so drop it. Instead if
the firmware needs to be able to find a specific node it should use a
platform specific compatible + properties for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
---
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index f8fb7e6..4474ef6 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -31,12 +31,10 @@ enable them. This way if e.g. later on support for more display clocks get
added, the simplefb nodes will already contain this info and the firmware
does not need to be updated.
-If pre-filled framebuffer nodes are used, they should be named
-"framebuffer#-<output>", e.g. "framebuffer0-hdmi". The output should be
-included in the name since different outputs typically require different
-clocks and the clocks are part of the pre-populated nodes. The firmware must
-rename the nodes to the standard "framebuffer@<address>" name using the
-runtime chosen address when enabling the nodes.
+If pre-filled framebuffer nodes are used, the firmware may need extra
+information to find the right node. In that case an extra platform specific
+compatible and platform specific properties should be used and documented,
+see e.g. simple-framebuffer-sunxi.txt .
Required properties:
- compatible: "simple-framebuffer"
--
2.1.0
^ permalink raw reply related
* [PATCH v3 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Hans de Goede @ 2014-11-18 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416309051-26784-1-git-send-email-hdegoede@redhat.com>
If pre-filled framebuffer nodes are used, the firmware may need extra
properties to find the right node. This documents the properties to use
for this on sunxi platforms.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
---
.../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
new file mode 100644
index 0000000..c46ba64
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
@@ -0,0 +1,33 @@
+Sunxi specific Simple Framebuffer bindings
+
+This binding documents sunxi specific extensions to the simple-framebuffer
+bindings. The sunxi simplefb u-boot code relies on the devicetree containing
+pre-populated simplefb nodes.
+
+These extensions are intended so that u-boot can select the right node based
+on which pipeline is being used. As such they are solely intended for
+firmware / bootloader use, and the OS should ignore them.
+
+Required properties:
+- compatible: "allwinner,simple-framebuffer"
+- allwinner,pipeline, one of:
+ "de_be0-lcd0"
+ "de_be1-lcd1"
+ "de_be0-lcd0-hdmi"
+ "de_be1-lcd1-hdmi"
+
+Example:
+
+chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framebuffer@0 {
+ compatible = "allwinner,simple-framebuffer", "simple-framebuffer";
+ allwinner,pipeline = "de_be0-lcd0-hdmi";
+ clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
+ <&ahb_gates 44>;
+ status = "disabled";
+ };
+};
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 3/4] simplefb: Change simplefb_init from module_init to fs_initcall
From: Thierry Reding @ 2014-11-18 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <546B26F4.50302@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3375 bytes --]
On Tue, Nov 18, 2014 at 12:01:08PM +0100, Hans de Goede wrote:
> Hi,
>
> On 11/18/2014 11:19 AM, Thierry Reding wrote:
> > On Thu, Nov 13, 2014 at 09:58:41AM +0100, Geert Uytterhoeven wrote:
> >> Hi Maxime,
> >>
> >> On Thu, Nov 13, 2014 at 9:52 AM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >>>> -module_init(simplefb_init);
> >>>> +/*
> >>>> + * While this can be a module, if builtin it's most likely the console
> >>>> + * So let's leave module_exit but move module_init to an earlier place
> >>>> + */
> >>>
> >>> Not really related to this patch itself, but do we want to support
> >>> simplefb as a module? It seems like it's going to be most of the time
> >>> broken.
> >>
> >> If it depends on clocks, it won't work as a module, as CCF will have disabled
> >> all unused clocks at that point.
> >
> > If it does depend on anything beyond clocks it won't work at all. Clocks
> > are special because they get set up very early at boot time. If it turns
> > out that a simplefb ever needs a regulator to remain on, and that's even
> > quite likely to happen eventually, it's going to fail miserably, because
> > those regulators will typically be provided by a PMIC on an I2C bus. The
> > regulator won't be registered until very late into the boot process and
> > a regulator_get() call will almost certainly cause the simplefb driver
> > to defer probing.
>
> Right, this has been discussed already and the plan is to have simplefb
> continue its probe function and return success from it if it encounters
> any -eprobe_defer errors, while tracking which resources it misses.
>
> And then have a late_initcall which will claim any resources which failed
> with -eprobe beforehand.
How do you ensure that the late_initcall gets run before any of the
other late_initcalls that disable the resources? Also my recollection is
that deferred probing will first be triggered the first time from a
late_initcall, so chances aren't very high that all resources have shown
up by that time.
> > Now deferring probing is a real showstopper for simplefb, because not
> > only does it make the framebuffer useless as early boot console, once
> > probing is attempted again the clocks that it would have needed to
> > acquire to keep going will already have been switched off, too.
>
> That is not true, even with the current implementation, if all necessary
> drivers are built in, then simplefb will come up later, but it will still
> come up before the late_initcall which disables the clocks.
Yes, in the current implementation because clocks typically are
registered very early and thus you don't hit the deferred probe. The
same is not true for other types of resources where it's actually quite
common to hit deferred probing (regulators is a very notorious one).
It doesn't matter whether a driver is built-in or not, once you hit
deferred probing you lose.
> Once we do the split probing described above (which is something which
> we plan to do when it becomes necessary), then simplefb will still come
> up early.
It will come up early but won't have acquired all the resources that it
needs, so unless you somehow manage to order late_initcalls in exactly
the way that you need them, the frameworks will still turn off what you
haven't managed to claim yet.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox