* Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
From: Tony Lindgren @ 2014-11-14 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5465AFF6.506@ti.com>
* Tero Kristo <t-kristo@ti.com> [141113 23:33]:
> On 11/14/2014 01:58 AM, Tony Lindgren wrote:
>
> The PRCM/clock cleanups that I have under work basically splits the clock
> inits under their respective IP blocks; currently everything is registered
> under generic PRCM. System control module will be one of the clock providers
> (and is going to look like a driver), which will be registering its own
> clocks.
Yes that's nice. The clock modules in the SCM should probably use the
syscon mapping unless there's a clear separate IO area for them. And
then use pinctrl for registers that are muxes for external pins unless
they are in some dedicated clock register area.
> This doesn't change the fact that pinctrl is directly mapping its
> own register space atm though, it might be possible to re-route this to use
> the generic system control module if need be though.
Mapping dedicated IO areas to individual drivers is not a problem. These
drivers can eventually be children of a core SCM driver if needed.
> I guess its just a political decision which way we want to go, currently we
> have lots of system control clocks under the clock data (for
> AM33xx,AM43xx,OMAP3), but we can remove these easily if need be. In some
> cases it is nicer to have the data in the clock tree though, the drivers
> don't need to care if they are touching a clock or a pinctrl entity. Some
> people have been converting additional stuff to CCF outside of PRCM, like
> Archit did some work to try and get control module clock support for DRA7,
> and Tomi has been talking to convert some of the DSS internal clocks to CCF
> also.
Setting up CCF drivers for SCM makes sense to me. I suggest the
following guidelines:
1. If there's a clear separate dedicated IO area in SCM, it can be
a driver implementing a Linux generic framework for CCF, regulators,
pinctrl, or PHY.
2. For the random control registers, we should use syscon or
pinctrl-single to implement Linux generic framwork functions for
CCF, regulators, pinctrl or PHY.
3. For resource management, we can have a core SCM driver that takes
care of the save and restore of registers and clocking if needed.
I believe currently SCM clocks are always enabled though. We can
set the drivers in #1 and #2 abobe to be childer of the core SCM
driver if we ever need to manage clocks during runtime.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device
From: Henrik Rydberg @ 2014-11-14 19:11 UTC (permalink / raw)
To: Bruno Prémont
Cc: Peter Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Bjorn Helgaas, linux-fbdev, linux-kernel
In-Reply-To: <20141114154252.0fb66bba@pluto.restena.lu>
Hi Bruno,
> So it would need to at least be select VGA_ARB if (PCI && !S390)
> in order to not have broken kernel configuration (in more or less
> exotic cases) while depends on VGA_ARB would be the only correct option
> if the rule 'select only allowed for leafs' is enforced.
Here is a tested patch that does just that, thanks for the suggestion.
Henrik
From 43c16bbc7adbcb17aac73d09f046bf2779771c4c Mon Sep 17 00:00:00 2001
From: Henrik Rydberg <rydberg@euromail.se>
Date: Fri, 14 Nov 2014 20:01:21 +0100
Subject: [PATCH v2] x86, ia64: Do not lose track of the EFI default VGA device
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Since commit 20cde694 in the 3.17 merge window, the EFI framebuffer
depends on the VGA arbitration layer. However, the configuration does
not reflect this, which leads to a hard-to-find bug when FB_EFI is
configured without VGA_ARB. Add a select clause to remedy this.
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
drivers/video/fbdev/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c7bf606..1615a1b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -761,6 +761,7 @@ config FB_EFI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VGA_ARB if (PCI && !S390)
help
This is the EFI frame buffer device driver. If the firmware on
your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
--
2.1.3
^ permalink raw reply related
* Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device
From: Bruno Prémont @ 2014-11-14 22:11 UTC (permalink / raw)
To: Henrik Rydberg
Cc: linux-fbdev, Peter Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Bjorn Helgaas, linux-kernel
In-Reply-To: <20141114191157.GA1648@polaris.bitmath.org>
Hi Hendrick,
On Fri, 14 November 2014 Henrik Rydberg <rydberg@euromail.se> wrote:
> > So it would need to at least be select VGA_ARB if (PCI && !S390)
> > in order to not have broken kernel configuration (in more or less
> > exotic cases) while depends on VGA_ARB would be the only correct option
> > if the rule 'select only allowed for leafs' is enforced.
>
> Here is a tested patch that does just that, thanks for the suggestion.
Sure it will cover your case but with a few issues.
As you might have noted, VGA_ARB can only be disabled if you select
EXPERT. In that case you kind of give up warranty.
In addition, prior to the patches that landed in 3.17, just selecting
X86_SYSFB would runtime-disable EFI_FB disabling boot_vga tagging
based on screen_info as well.
Stating in the commit message that EFI_FB depends on VGA_ARB is pretty
wrong. A more correct phrasing would be that before the commit EFI_FB
included boot_vga detection which has been moved around, but that
feature is not inherent to EFI_FB. Doing the select only keeps
`make oldconfig` provide the same feature set.
As boot_vga is a PCI thing maybe the whole detection should effectively
be fully dissociated from runtime GPU switching and be adjusted to
really only flag the boot GPU (even when there is no VGA around).
Unfortunately this attribute is not explicitly documented so drawing the
line one way or another may trip on some user's feet.
We have some more or less conflicting information in commit messages though:
217f45de3d2 by Dave Airlie introducing boot_vgain 2009:
PCI: expose boot VGA device via sysfs.
X really would like to know which VGA device was considered the boot
device by the system. The x86 PCI fixups have support for discovering
this but we provide no way to expose it to userspace.
This adds a sysfs file per VGA class device which has the value 0 for
non the boot device or unknown, and 1 if the VGA device is the boot
device.
1a39b310e92 by Matthew Garrett making it variable in 2012:
vgaarb: Add support for setting the default video device (v2)
The default VGA device is a somewhat fluid concept on platforms with
multiple GPUs. Add support for setting it so switching code can update
things appropriately, and make sure that the sysfs code returns the right
device if it's changed.
So should boot_vga now represent the main GPU of the system or should
it represent the one(s) that were used for booting? (I've not heard
of systems with more than one active firmware GPU... but why not!
Matthew covered the case where multiple GPUs are in a set where only one
of them can be active as in driving displays. Maybe this would need some
alternative sysfs attribute kind of "preferred_gpu".
Bruno
> From 43c16bbc7adbcb17aac73d09f046bf2779771c4c Mon Sep 17 00:00:00 2001
> From: Henrik Rydberg <rydberg@euromail.se>
> Date: Fri, 14 Nov 2014 20:01:21 +0100
> Subject: [PATCH v2] x86, ia64: Do not lose track of the EFI default VGA device
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Since commit 20cde694 in the 3.17 merge window, the EFI framebuffer
> depends on the VGA arbitration layer. However, the configuration does
> not reflect this, which leads to a hard-to-find bug when FB_EFI is
> configured without VGA_ARB. Add a select clause to remedy this.
>
> Cc: Bruno Prémont <bonbons@linux-vserver.org>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> drivers/video/fbdev/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index c7bf606..1615a1b 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -761,6 +761,7 @@ config FB_EFI
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> + select VGA_ARB if (PCI && !S390)
> help
> This is the EFI frame buffer device driver. If the firmware on
> your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
^ permalink raw reply
* Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
From: Vladimir Zapolskiy @ 2014-11-15 15:52 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen
In-Reply-To: <5466139E.5040308@mentor.com>
Hi Jyri,
On 14.11.2014 16:37, 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
>
> Otherwise I'm worried that someone's git rebase may fail.
sorry, git bisect of course.
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: SSD1306 OLED driver
From: maxime.ripard @ 2014-11-16 9:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Hi,
On Fri, Nov 14, 2014 at 05:09:09PM +0530, Ssagarr Patil wrote:
> Hi,
>
> I have the SSD1306 oled device connected via spi, will the same
> driver work ? as the current one is based on i2c what all mods would
> be required to have it working with SPI ?
It won't work out of the box, but it should be fairly easy to support.
You need to had support for SPI probing, and then provide some generic
accessors the rest of the code can use to wrap around the i2c and spi
calls.
I'm not sure regmap can be used for this, but this would be something
worth looking into to do that.
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
* [PATCH] video: ARM CLCD: Remove duplicated include in amba-clcd.c
From: Qiang Chen @ 2014-11-17 9:25 UTC (permalink / raw)
To: tomi.valkeinen, plagnioj, linux, pawel.moll
Cc: linux-fbdev, linux-kernel, qcwj.lk
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>
--
1.8.2.2
^ permalink raw reply related
* 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
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