* Re: [PATCHv4][ 2/6] dma: ipu: Add devicetree support.
From: Sascha Hauer @ 2013-11-05 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383581724-14817-2-git-send-email-denis@eukrea.com>
On Mon, Nov 04, 2013 at 05:15:20PM +0100, Denis Carikli wrote:
> diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-ipu.txt b/Documentation/devicetree/bindings/dma/fsl-imx-ipu.txt
> new file mode 100644
> index 0000000..2f3c976
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/fsl-imx-ipu.txt
> @@ -0,0 +1,20 @@
> +* Freescale Image Processing Unit (IPU) support for i.MX3x.
> +
> +This driver supports the imx31 and imx35 devices.
> +
> +Required properties:
> +- compatible : Should be "fsl,imx31-ipu".
> +- reg : Should contain IPU registers location and length.
> +- interrupts : First item should be IPU interrupt, second one is optional and
> + should contain IPU Error interrupt.
> +
> +Example:
> +
> + ipu: ipu@53fc0000 {
> + compatible = "fsl,imx31-ipu";
> + reg = < 0x53fc0000 0x5f
> + 0x53fc0088 0x2b >;
> + interrupts = <42 41>;
> + clocks = <&clks 55>;
> + clock-names = "";
> + };
As said before: I don't think that splitting the IPU in several nodes
like above just to satisfy the current Linux driver setup is
appropriate.
The IPU should rather look like:
ipu: ipu@53fc0000 {
compatible = "fsl,imx31-ipu";
reg = <0x53fc0000 0x4000>;
interrupts = <42 31>;
clocks = <&clks 55 ...>;
clock-names = "...";
};
Note that the above covers the whole address space of the IPU. This is
more close to the IPUv3 binding. With separating the IDMAC and DI nodes
you force us to keep the current driver separation between dma and fb
driver. The IPU should never have used the Linux DMA driver framework
though.
When you cover the whole address space you could then in the
corresponding driver register platform devices which match to the
current dma/fb driver combination.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv4][ 1/6] fbdev: Add the lacking FB_SYNC_* for matching the DISPLAY_FLAGS_*
From: Geert Uytterhoeven @ 2013-11-04 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383581724-14817-1-git-send-email-denis@eukrea.com>
On Mon, Nov 4, 2013 at 5:15 PM, Denis Carikli <denis@eukrea.com> wrote:
> --- a/include/uapi/linux/fb.h
> +++ b/include/uapi/linux/fb.h
> +#define FB_SYNC_DE_HIGH_ACT 64 /* data enable high active */
> +#define FB_SYNC_PIXDAT_HIGH_ACT 128 /* data enable high active */
copy and paste of the comment above?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] video/logo: Remove MIPS-specific include section
From: Ralf Baechle @ 2013-11-04 17:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-mips
In-Reply-To: <1383554550-20901-1-git-send-email-geert@linux-m68k.org>
On Mon, Nov 04, 2013 at 09:42:30AM +0100, Geert Uytterhoeven wrote:
> Since commit 41702d9a4fffa9e25b2ad9d4af09b3013fa155e1 ("logo.c: get rid of
> mips_machgroup") there's no longer a need to include <asm/bootinfo.h> on
> MIPS.
Yes,
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Generally CONFIG_<ARCH> should probably be considered a bug even if only
it's used to hide crap like this.
Ralf
^ permalink raw reply
* Re: [PATCHv4][ 5/6] ARM: dts: i.MX35: Add display support.
From: Fabio Estevam @ 2013-11-04 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383581724-14817-5-git-send-email-denis@eukrea.com>
Hi Denis,
On Mon, Nov 4, 2013 at 2:15 PM, Denis Carikli <denis@eukrea.com> wrote:
> + ipu: ipu@53fc0000 {
> + compatible = "fsl,imx31-ipu";
> + reg = < 0x53fc0000 0x5f
> + 0x53fc0088 0x2b >;
> + interrupts = <42 41>;
> + clocks = <&clks 55>;
> + status = "disabled";
> + };
> +
> + lcdc: mx3fb@53fc00b4 {
> + compatible = "fsl,mx3-fb";
> + reg = <0x53fc00b4 0x0b>;
> + clocks = <&clks 55>;
> + status = "disabled";
> + };
MX35 Reference Manual states that the IPU address range is 0x53fc0000
- 0x53fc3fff
There is no 'lcdc' peripheral listed there, so I don't think 'lcdc'
should be included here.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCHv4][ 6/6] ARM: dts: mbimxsd35 Add video and displays support.
From: Denis Carikli @ 2013-11-04 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383581724-14817-1-git-send-email-denis@eukrea.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v3->v4:
- Shortened the licenses.
- adapted the dts(i) to the new bindings.
ChangeLog v2->v3:
- The dts were adapted to the new DT bindings which looks more like the IPUv3
ones.
---
.../imx35-eukrea-mbimxsd35-baseboard-cmo-qvga.dts | 62 ++++++++++++++++++++
.../imx35-eukrea-mbimxsd35-baseboard-dvi-svga.dts | 51 ++++++++++++++++
.../imx35-eukrea-mbimxsd35-baseboard-dvi-vga.dts | 52 ++++++++++++++++
3 files changed, 165 insertions(+)
create mode 100644 arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-cmo-qvga.dts
create mode 100644 arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-dvi-svga.dts
create mode 100644 arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-dvi-vga.dts
diff --git a/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-cmo-qvga.dts b/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-cmo-qvga.dts
new file mode 100644
index 0000000..b060f08
--- /dev/null
+++ b/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-cmo-qvga.dts
@@ -0,0 +1,62 @@
+/*
+ * Copyright 2013 Eukréa Electromatique <denis@eukrea.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "imx35-eukrea-mbimxsd35-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD35 with the CMO-QVGA Display";
+ compatible = "eukrea,mbimxsd35-baseboard-cmo-qvga", "eukrea,mbimxsd35-baseboard", "eukrea,cpuimx35", "fsl,imx35";
+
+ cmo_qvga: display@di0 {
+ compatible = "fsl,mx3-parallel-display";
+ regulator-name = "lcd";
+ interface-pix-fmt = "rgb666";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdc_1>;
+ lcd-supply = <®_lcd_3v3>;
+ model = "CMO-QVGA";
+ display-timings {
+ qvga_timings: 320x240 {
+ clock-frequency = <6500000>;
+ hactive = <320>;
+ vactive = <240>;
+ hback-porch = <68>;
+ hfront-porch = <20>;
+ vback-porch = <15>;
+ vfront-porch = <4>;
+ hsync-len = <30>;
+ vsync-len = <3>;
+ };
+ };
+ };
+
+ reg_lcd_3v3: lcd-en {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_lcd_3v3>;
+ regulator-name = "lcd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 4 0>;
+ enable-active-high;
+ };
+};
+
+&ipu {
+ status = "okay";
+};
+
+&lcdc {
+ display = <&cmo_qvga>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-dvi-svga.dts b/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-dvi-svga.dts
new file mode 100644
index 0000000..ec1a713
--- /dev/null
+++ b/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-dvi-svga.dts
@@ -0,0 +1,51 @@
+/*
+ * Copyright 2013 Eukréa Electromatique <denis@eukrea.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "imx35-eukrea-mbimxsd35-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD35 with the DVI-SVGA Display";
+ compatible = "eukrea,mbimxsd35-baseboard-dvi-svga", "eukrea,mbimxsd35-baseboard", "eukrea,cpuimx35", "fsl,imx35";
+ dvi_svga: display@di0 {
+ interface-pix-fmt = "rgb666";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdc_1>;
+ model = "DVI-SVGA";
+ display-timings {
+ svga_timings: 800x600 {
+ clock-frequency = <40000000>;
+ hactive = <800>;
+ vactive = <600>;
+ hback-porch = <75>;
+ hfront-porch = <75>;
+ vback-porch = <7>;
+ vfront-porch = <75>;
+ hsync-len = <7>;
+ vsync-len = <7>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+ };
+};
+
+&ipu {
+ status = "okay";
+};
+
+&lcdc {
+ display = <&dvi_svga>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-dvi-vga.dts b/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-dvi-vga.dts
new file mode 100644
index 0000000..9e3d08a
--- /dev/null
+++ b/arch/arm/boot/dts/imx35-eukrea-mbimxsd35-baseboard-dvi-vga.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2013 Eukréa Electromatique <denis@eukrea.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "imx35-eukrea-mbimxsd35-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD35 with the DVI-VGA Display";
+ compatible = "eukrea,mbimxsd35-baseboard-dvi-vga", "eukrea,mbimxsd35-baseboard", "eukrea,cpuimx35", "fsl,imx35";
+ dvi_vga: display@di0 {
+ interface-pix-fmt = "rgb666";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdc_1>;
+ model = "DVI-VGA";
+ display-timings {
+ vga_timings: 640x480 {
+ clock-frequency = <31250000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <100>;
+ hfront-porch = <100>;
+ vback-porch = <7>;
+ vfront-porch = <100>;
+ hsync-len = <7>;
+ vsync-len = <7>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+ };
+};
+
+
+&ipu {
+ status = "okay";
+};
+
+&lcdc {
+ display = <&dvi_vga>;
+ status = "okay";
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCHv4][ 5/6] ARM: dts: i.MX35: Add display support.
From: Denis Carikli @ 2013-11-04 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383581724-14817-1-git-send-email-denis@eukrea.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v3->v4:
- Splitted the imx35.dtsi display support (new patch).
---
arch/arm/boot/dts/imx35.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 0f67f22..9a46146 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -349,6 +349,22 @@
status = "disabled";
};
+ ipu: ipu@53fc0000 {
+ compatible = "fsl,imx31-ipu";
+ reg = < 0x53fc0000 0x5f
+ 0x53fc0088 0x2b >;
+ interrupts = <42 41>;
+ clocks = <&clks 55>;
+ status = "disabled";
+ };
+
+ lcdc: mx3fb@53fc00b4 {
+ compatible = "fsl,mx3-fb";
+ reg = <0x53fc00b4 0x0b>;
+ clocks = <&clks 55>;
+ status = "disabled";
+ };
+
audmux: audmux@53fc4000 {
compatible = "fsl,imx35-audmux", "fsl,imx31-audmux";
reg = <0x53fc4000 0x4000>;
--
1.7.9.5
^ permalink raw reply related
* [PATCHv4][ 4/6] video: mx3fb: Introduce regulator support.
From: Denis Carikli @ 2013-11-04 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383581724-14817-1-git-send-email-denis@eukrea.com>
This commit is based on the following commit by Fabio Estevam:
4344429 video: mxsfb: Introduce regulator support
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v3->v4:
- Some code style fixes.
- Improved error handling in eremap.
ChangeLog v2->v3:
- The prints are now replaced with non line wrapped prints.
- The regulator retrival has been adapted to the new DT bindings which looks
more like the IPUv3 ones.
- The regulator_is_enabled checks were kept, because regulator_disable do not
do such check.
---
drivers/video/mx3fb.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 70 insertions(+), 1 deletion(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index 75087c8..fd8df64 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -27,6 +27,7 @@
#include <linux/clk.h>
#include <linux/mutex.h>
#include <linux/dma/ipu-dma.h>
+#include <linux/regulator/consumer.h>
#include <linux/platform_data/dma-imx.h>
#include <linux/platform_data/video-mx3fb.h>
@@ -269,6 +270,7 @@ struct mx3fb_info {
struct dma_async_tx_descriptor *txd;
dma_cookie_t cookie;
struct scatterlist sg[2];
+ struct regulator *reg_lcd;
struct fb_var_screeninfo cur_var; /* current var info */
};
@@ -1005,6 +1007,7 @@ static void __blank(int blank, struct fb_info *fbi)
struct mx3fb_info *mx3_fbi = fbi->par;
struct mx3fb_data *mx3fb = mx3_fbi->mx3fb;
int was_blank = mx3_fbi->blank;
+ int ret;
mx3_fbi->blank = blank;
@@ -1023,6 +1026,15 @@ static void __blank(int blank, struct fb_info *fbi)
case FB_BLANK_HSYNC_SUSPEND:
case FB_BLANK_NORMAL:
sdc_set_brightness(mx3fb, 0);
+ if (mx3_fbi->reg_lcd) {
+ if (regulator_is_enabled(mx3_fbi->reg_lcd)) {
+ ret = regulator_disable(mx3_fbi->reg_lcd);
+ if (ret)
+ dev_warn(fbi->device,
+ "lcd regulator disable failed with error: %d\n",
+ ret);
+ }
+ }
memset((char *)fbi->screen_base, 0, fbi->fix.smem_len);
/* Give LCD time to update - enough for 50 and 60 Hz */
msleep(25);
@@ -1030,6 +1042,15 @@ static void __blank(int blank, struct fb_info *fbi)
break;
case FB_BLANK_UNBLANK:
sdc_enable_channel(mx3_fbi);
+ if (mx3_fbi->reg_lcd) {
+ if (!regulator_is_enabled(mx3_fbi->reg_lcd)) {
+ ret = regulator_enable(mx3_fbi->reg_lcd);
+ if (ret)
+ dev_warn(fbi->device,
+ "lcd regulator enable failed with error: %d\n",
+ ret);
+ }
+ }
sdc_set_brightness(mx3fb, mx3fb->backlight_level);
break;
}
@@ -1206,6 +1227,7 @@ static int mx3fb_suspend(struct platform_device *pdev, pm_message_t state)
{
struct mx3fb_data *mx3fb = platform_get_drvdata(pdev);
struct mx3fb_info *mx3_fbi = mx3fb->fbi->par;
+ int ret;
console_lock();
fb_set_suspend(mx3fb->fbi, 1);
@@ -1214,7 +1236,15 @@ static int mx3fb_suspend(struct platform_device *pdev, pm_message_t state)
if (mx3_fbi->blank = FB_BLANK_UNBLANK) {
sdc_disable_channel(mx3_fbi);
sdc_set_brightness(mx3fb, 0);
-
+ if (mx3_fbi->reg_lcd) {
+ if (regulator_is_enabled(mx3_fbi->reg_lcd)) {
+ ret = regulator_disable(mx3_fbi->reg_lcd);
+ if (ret)
+ dev_warn(&pdev->dev,
+ "lcd regulator disable failed with error: %d\n",
+ ret);
+ }
+ }
}
return 0;
}
@@ -1226,10 +1256,20 @@ static int mx3fb_resume(struct platform_device *pdev)
{
struct mx3fb_data *mx3fb = platform_get_drvdata(pdev);
struct mx3fb_info *mx3_fbi = mx3fb->fbi->par;
+ int ret;
if (mx3_fbi->blank = FB_BLANK_UNBLANK) {
sdc_enable_channel(mx3_fbi);
sdc_set_brightness(mx3fb, mx3fb->backlight_level);
+ if (mx3_fbi->reg_lcd) {
+ if (!regulator_is_enabled(mx3_fbi->reg_lcd)) {
+ ret = regulator_enable(mx3_fbi->reg_lcd);
+ if (ret)
+ dev_warn(&pdev->dev,
+ "lcd regulator enable failed with error: %d\n",
+ ret);
+ }
+ }
}
console_lock();
@@ -1373,6 +1413,7 @@ static int init_fb_chan(struct mx3fb_data *mx3fb, struct idmac_channel *ichan)
struct mx3fb_platform_data *mx3fb_pdata = dev->platform_data;
struct device_node *np = dev->of_node;
const char *name;
+ const char *regulator_name;
const char *ipu_disp_format;
unsigned int irq;
struct fb_info *fbi;
@@ -1389,6 +1430,9 @@ static int init_fb_chan(struct mx3fb_data *mx3fb, struct idmac_channel *ichan)
return -EINVAL;
}
+ of_property_read_string(display_np, "regulator-name",
+ ®ulator_name);
+
of_property_read_string(display_np, "interface-pix-fmt",
&ipu_disp_format);
if (!ipu_disp_format) {
@@ -1503,6 +1547,25 @@ static int init_fb_chan(struct mx3fb_data *mx3fb, struct idmac_channel *ichan)
if (ret < 0)
goto erfb;
+ /* In dt mode,
+ * using devm_regulator_get would require that the proprety referencing
+ * the regulator phandle has to be inside the mx3fb node.
+ */
+ if (np) {
+ if (regulator_name)
+ mx3fbi->reg_lcd = regulator_get(NULL, regulator_name);
+ } else {
+ mx3fbi->reg_lcd = devm_regulator_get(dev, "lcd");
+ }
+
+ if (IS_ERR(mx3fbi->reg_lcd)) {
+ dev_warn(mx3fb->dev, "Operating without regulator \"lcd\"\n");
+ mx3fbi->reg_lcd = NULL;
+ } else {
+ dev_info(mx3fb->dev, "Using \"%s\" Regulator\n",
+ regulator_name);
+ }
+
return 0;
erfb:
@@ -1569,6 +1632,7 @@ static int mx3fb_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
struct dma_chan *chan;
struct dma_chan_request rq;
+ struct mx3fb_info *mx3_fbi;
/*
* Display Interface (DI) and Synchronous Display Controller (SDC)
@@ -1624,6 +1688,11 @@ ersdc0:
dmaengine_put();
iounmap(mx3fb->reg_base);
eremap:
+ if (mx3fb->fbi) {
+ mx3_fbi = mx3fb->fbi->par;
+ if (mx3_fbi->reg_lcd)
+ regulator_put(mx3_fbi->reg_lcd);
+ }
kfree(mx3fb);
dev_err(dev, "mx3fb: failed to register fb\n");
return ret;
--
1.7.9.5
^ permalink raw reply related
* [PATCHv4][ 3/6] video: mx3fb: Add device tree suport.
From: Denis Carikli @ 2013-11-04 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383581724-14817-1-git-send-email-denis@eukrea.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v3->v4:
- Updated bindings.
- Updated documentation accordinly.
- Updated code accordinly.
- Fixed the lack of "ret =" in
of_property_read_string(display_np, "model", &name);
- Supressed some compilation warnings.
ChangeLog v2->v3:
- The device tree bindings were reworked in order to make it look more like the
IPUv3 bindings.
- The interface_pix_fmt property now looks like the IPUv3 one.
---
.../devicetree/bindings/video/fsl,mx3-fb.txt | 42 +++++++
drivers/video/Kconfig | 2 +
drivers/video/mx3fb.c | 119 +++++++++++++++++---
3 files changed, 148 insertions(+), 15 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/fsl,mx3-fb.txt
diff --git a/Documentation/devicetree/bindings/video/fsl,mx3-fb.txt b/Documentation/devicetree/bindings/video/fsl,mx3-fb.txt
new file mode 100644
index 0000000..60faff5
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,mx3-fb.txt
@@ -0,0 +1,42 @@
+Freescale MX3 framebuffer.
+=============
+
+Required properties:
+- compatible: Should be "fsl,mx3fb". compatible chips include the imx31 and the
+ imx35.
+- reg: should be register base and length as documented in the datasheet.
+- clocks: Handle to the ipu_gate clock.
+- display: Phandle to a "fsl,mx3-parallel-display" compatible display node.
+
+Example:
+
+lcdc: mx3fb@53fc00b4 {
+ compatible = "fsl,mx3-fb";
+ reg = <0x53fc00b4 0x0b>;
+ clocks = <&clks 55>;
+};
+
+Display support
+=======+Required properties:
+- compatible: Should be "fsl,mx3-parallel-display".
+- model : The user-visible name of the display.
+
+Optional properties:
+- interface_pix_fmt: How this display is connected to the
+ crtc. Currently supported types: "rgb24", "rgb565", "rgb666".
+
+It can also have an optional timing subnode as described in
+ Documentation/devicetree/bindings/video/display-timing.txt.
+
+Example:
+
+display0: display@di0 {
+ compatible = "fsl,mx3-parallel-display";
+ interface-pix-fmt = "rgb666";
+ model = "CMO-QVGA";
+};
+
+&lcdc {
+ display = <&display0>;
+}
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 84b685f..edcfa33 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2357,6 +2357,8 @@ config FB_MX3
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VIDEOMODE_HELPERS
+ select FB_MODE_HELPERS
default y
help
This is a framebuffer device for the i.MX31 LCD Controller. So
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index cfdb380..75087c8 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -31,6 +31,8 @@
#include <linux/platform_data/dma-imx.h>
#include <linux/platform_data/video-mx3fb.h>
+#include <video/of_display_timing.h>
+
#include <asm/io.h>
#include <asm/uaccess.h>
@@ -757,11 +759,13 @@ static int __set_par(struct fb_info *fbi, bool lock)
sig_cfg.Hsync_pol = true;
if (fbi->var.sync & FB_SYNC_VERT_HIGH_ACT)
sig_cfg.Vsync_pol = true;
- if (fbi->var.sync & FB_SYNC_CLK_INVERT)
+ if ((fbi->var.sync & FB_SYNC_CLK_INVERT) ||
+ (fbi->var.sync & FB_SYNC_PIXDAT_HIGH_ACT))
sig_cfg.clk_pol = true;
if (fbi->var.sync & FB_SYNC_DATA_INVERT)
sig_cfg.data_pol = true;
- if (fbi->var.sync & FB_SYNC_OE_ACT_HIGH)
+ if ((fbi->var.sync & FB_SYNC_OE_ACT_HIGH) ||
+ (fbi->var.sync & FB_SYNC_DE_HIGH_ACT))
sig_cfg.enable_pol = true;
if (fbi->var.sync & FB_SYNC_CLK_IDLE_EN)
sig_cfg.clkidle_en = true;
@@ -1351,21 +1355,69 @@ static struct fb_info *mx3fb_init_fbinfo(struct device *dev, struct fb_ops *ops)
return fbi;
}
+static int match_dt_disp_data(const char *property)
+{
+ if (!strcmp("rgb666", property))
+ return IPU_DISP_DATA_MAPPING_RGB666;
+ else if (!strcmp("rgb565", property))
+ return IPU_DISP_DATA_MAPPING_RGB565;
+ else if (!strcmp("rgb24", property))
+ return IPU_DISP_DATA_MAPPING_RGB888;
+ else
+ return -EINVAL;
+}
+
static int init_fb_chan(struct mx3fb_data *mx3fb, struct idmac_channel *ichan)
{
struct device *dev = mx3fb->dev;
struct mx3fb_platform_data *mx3fb_pdata = dev->platform_data;
- const char *name = mx3fb_pdata->name;
+ struct device_node *np = dev->of_node;
+ const char *name;
+ const char *ipu_disp_format;
unsigned int irq;
struct fb_info *fbi;
struct mx3fb_info *mx3fbi;
const struct fb_videomode *mode;
int ret, num_modes;
+ struct fb_videomode of_mode;
+ struct device_node *display_np;
+
+ if (np) {
+ display_np = of_parse_phandle(np, "display", 0);
+ if (!display_np) {
+ dev_err(dev, "Can't get the display device node.\n");
+ return -EINVAL;
+ }
+
+ of_property_read_string(display_np, "interface-pix-fmt",
+ &ipu_disp_format);
+ if (!ipu_disp_format) {
+ mx3fb->disp_data_fmt = IPU_DISP_DATA_MAPPING_RGB666;
+ dev_warn(dev,
+ "ipu display data mapping was not defined, using the default rgb666.\n");
+ } else {
+ mx3fb->disp_data_fmt + match_dt_disp_data(ipu_disp_format);
+ }
+
+ if (mx3fb->disp_data_fmt = -EINVAL) {
+ dev_err(dev, "Illegal display data format \"%s\"\n",
+ ipu_disp_format);
+ return -EINVAL;
+ }
- if (mx3fb_pdata->disp_data_fmt >= ARRAY_SIZE(di_mappings)) {
- dev_err(dev, "Illegal display data format %d\n",
+ ret = of_property_read_string(display_np, "model", &name);
+ if (ret) {
+ dev_err(dev, "Missing display model name\n");
+ return -EINVAL;
+ }
+ } else {
+ name = mx3fb_pdata->name;
+ if (mx3fb_pdata->disp_data_fmt >= ARRAY_SIZE(di_mappings)) {
+ dev_err(dev, "Illegal display data format %d\n",
mx3fb_pdata->disp_data_fmt);
- return -EINVAL;
+ return -EINVAL;
+ }
}
ichan->client = mx3fb;
@@ -1386,12 +1438,24 @@ static int init_fb_chan(struct mx3fb_data *mx3fb, struct idmac_channel *ichan)
goto emode;
}
- if (mx3fb_pdata->mode && mx3fb_pdata->num_modes) {
- mode = mx3fb_pdata->mode;
- num_modes = mx3fb_pdata->num_modes;
+ if (np) {
+ ret = of_get_fb_videomode(display_np, &of_mode,
+ OF_USE_NATIVE_MODE);
+ if (!ret) {
+ mode = &of_mode;
+ num_modes = 1;
+ } else {
+ mode = mx3fb_modedb;
+ num_modes = ARRAY_SIZE(mx3fb_modedb);
+ }
} else {
- mode = mx3fb_modedb;
- num_modes = ARRAY_SIZE(mx3fb_modedb);
+ if (mx3fb_pdata->mode || !mx3fb_pdata->num_modes) {
+ mode = mx3fb_pdata->mode;
+ num_modes = mx3fb_pdata->num_modes;
+ } else {
+ mode = mx3fb_modedb;
+ num_modes = ARRAY_SIZE(mx3fb_modedb);
+ }
}
if (!fb_find_mode(&fbi->var, fbi, fb_mode, mode,
@@ -1421,7 +1485,8 @@ static int init_fb_chan(struct mx3fb_data *mx3fb, struct idmac_channel *ichan)
mx3fbi->mx3fb = mx3fb;
mx3fbi->blank = FB_BLANK_NORMAL;
- mx3fb->disp_data_fmt = mx3fb_pdata->disp_data_fmt;
+ if (!np)
+ mx3fb->disp_data_fmt = mx3fb_pdata->disp_data_fmt;
init_completion(&mx3fbi->flip_cmpl);
disable_irq(ichan->eof_irq);
@@ -1449,13 +1514,26 @@ emode:
return ret;
}
+static int imx_dma_is_dt_ipu(struct dma_chan *chan)
+{
+ /* Example: 53fc0000.ipu */
+ if (chan && chan->device && chan->device->dev) {
+ const char *name = dev_name(chan->device->dev);
+ name = strchr(name, '.');
+ if (name)
+ return !strcmp(name, ".ipu");
+ }
+
+ return 0;
+}
+
static bool chan_filter(struct dma_chan *chan, void *arg)
{
struct dma_chan_request *rq = arg;
struct device *dev;
struct mx3fb_platform_data *mx3fb_pdata;
- if (!imx_dma_is_ipu(chan))
+ if (!imx_dma_is_ipu(chan) && !imx_dma_is_dt_ipu(chan))
return false;
if (!rq)
@@ -1464,8 +1542,12 @@ static bool chan_filter(struct dma_chan *chan, void *arg)
dev = rq->mx3fb->dev;
mx3fb_pdata = dev->platform_data;
- return rq->id = chan->chan_id &&
- mx3fb_pdata->dma_dev = chan->device->dev;
+ /* When using the devicetree, mx3fb_pdata is NULL */
+ if (imx_dma_is_dt_ipu(chan))
+ return rq->id = chan->chan_id;
+ else
+ return rq->id = chan->chan_id &&
+ mx3fb_pdata->dma_dev = chan->device->dev;
}
static void release_fbi(struct fb_info *fbi)
@@ -1565,9 +1647,16 @@ static int mx3fb_remove(struct platform_device *dev)
return 0;
}
+static struct of_device_id mx3fb_of_dev_id[] = {
+ { .compatible = "fsl,mx3-fb", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mx3fb_of_dev_id);
+
static struct platform_driver mx3fb_driver = {
.driver = {
.name = MX3FB_NAME,
+ .of_match_table = mx3fb_of_dev_id,
.owner = THIS_MODULE,
},
.probe = mx3fb_probe,
--
1.7.9.5
^ permalink raw reply related
* [PATCHv4][ 2/6] dma: ipu: Add devicetree support.
From: Denis Carikli @ 2013-11-04 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383581724-14817-1-git-send-email-denis@eukrea.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v3->v4:
- Synced the documentation with the code.
ChangeLog v2->v3:
- The DMA channels are not exposed anymore in order to look more like the IPUv3
bindings.
---
.../devicetree/bindings/dma/fsl-imx-ipu.txt | 20 ++++++++++++++++++++
drivers/dma/ipu/ipu_idmac.c | 8 ++++++++
2 files changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/fsl-imx-ipu.txt
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-ipu.txt b/Documentation/devicetree/bindings/dma/fsl-imx-ipu.txt
new file mode 100644
index 0000000..2f3c976
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-ipu.txt
@@ -0,0 +1,20 @@
+* Freescale Image Processing Unit (IPU) support for i.MX3x.
+
+This driver supports the imx31 and imx35 devices.
+
+Required properties:
+- compatible : Should be "fsl,imx31-ipu".
+- reg : Should contain IPU registers location and length.
+- interrupts : First item should be IPU interrupt, second one is optional and
+ should contain IPU Error interrupt.
+
+Example:
+
+ ipu: ipu@53fc0000 {
+ compatible = "fsl,imx31-ipu";
+ reg = < 0x53fc0000 0x5f
+ 0x53fc0088 0x2b >;
+ interrupts = <42 41>;
+ clocks = <&clks 55>;
+ clock-names = "";
+ };
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index cb9c0bc..d853ee1 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -22,6 +22,7 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/dma/ipu-dma.h>
#include "../dmaengine.h"
@@ -1768,6 +1769,12 @@ static int ipu_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id ipu_dma_of_dev_id[] = {
+ { .compatible = "fsl,imx31-ipu", },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ipu_dma_of_dev_id);
+
/*
* We need two MEM resources - with IPU-common and Image Converter registers,
* including PF_CONF and IDMAC_* registers, and two IRQs - function and error
@@ -1775,6 +1782,7 @@ static int ipu_remove(struct platform_device *pdev)
static struct platform_driver ipu_platform_driver = {
.driver = {
.name = "ipu-core",
+ .of_match_table = of_match_ptr(ipu_dma_of_dev_id),
.owner = THIS_MODULE,
},
.remove = ipu_remove,
--
1.7.9.5
^ permalink raw reply related
* [PATCHv4][ 1/6] fbdev: Add the lacking FB_SYNC_* for matching the DISPLAY_FLAGS_*
From: Denis Carikli @ 2013-11-04 16:15 UTC (permalink / raw)
To: linux-arm-kernel
Without that fix, drivers using the fb_videomode_from_videomode
function will not be able to get certain information because
some DISPLAY_FLAGS_* have no corresponding FB_SYNC_*.
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
ChangeLog v3->v4:
- Fixed the issue with FB_SYNC_PIXDAT_HIGH_ACT value.
ChangeLog v2->v3:
- Added Jean-Christophe PLAGNIOL-VILLARD's ACK.
---
drivers/video/fbmon.c | 4 ++++
include/uapi/linux/fb.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 6103fa6..29a9ed0 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1402,6 +1402,10 @@ int fb_videomode_from_videomode(const struct videomode *vm,
fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
if (vm->flags & DISPLAY_FLAGS_VSYNC_HIGH)
fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
+ fbmode->sync |= FB_SYNC_DE_HIGH_ACT;
+ if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
+ fbmode->sync |= FB_SYNC_PIXDAT_HIGH_ACT;
if (vm->flags & DISPLAY_FLAGS_INTERLACED)
fbmode->vmode |= FB_VMODE_INTERLACED;
if (vm->flags & DISPLAY_FLAGS_DOUBLESCAN)
diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h
index fb795c3..c618cfc 100644
--- a/include/uapi/linux/fb.h
+++ b/include/uapi/linux/fb.h
@@ -215,6 +215,8 @@ struct fb_bitfield {
/* vtotal = 144d/288n/576i => PAL */
/* vtotal = 121d/242n/484i => NTSC */
#define FB_SYNC_ON_GREEN 32 /* sync on green */
+#define FB_SYNC_DE_HIGH_ACT 64 /* data enable high active */
+#define FB_SYNC_PIXDAT_HIGH_ACT 128 /* data enable high active */
#define FB_VMODE_NONINTERLACED 0 /* non interlaced */
#define FB_VMODE_INTERLACED 1 /* interlaced */
--
1.7.9.5
^ permalink raw reply related
* [PATCH] video/logo: Remove MIPS-specific include section
From: Geert Uytterhoeven @ 2013-11-04 8:42 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Ralf Baechle, linux-fbdev, linux-mips, Geert Uytterhoeven
Since commit 41702d9a4fffa9e25b2ad9d4af09b3013fa155e1 ("logo.c: get rid of
mips_machgroup") there's no longer a need to include <asm/bootinfo.h> on
MIPS.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/video/logo/logo.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index 080c35b34bbb..b670cbda38e3 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -17,10 +17,6 @@
#include <asm/setup.h>
#endif
-#ifdef CONFIG_MIPS
-#include <asm/bootinfo.h>
-#endif
-
static bool nologo;
module_param(nologo, bool, 0);
MODULE_PARM_DESC(nologo, "Disables startup logo");
--
1.7.9.5
^ permalink raw reply related
* Re: outcome of DRM/KMS DT bindings session
From: Inki Dae @ 2013-11-01 15:28 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel, ksummit-2013-discuss, Linux Fbdev development list
In-Reply-To: <CAPM=9ty7+A=YjSbRLxmo9mXSQSkZsZngBvTsryZ8+tHppEMPyw@mail.gmail.com>
2013/11/1 Dave Airlie <airlied@gmail.com>:
>>> After looking at some of the ordering issues we've had with x86 GPUs
>>> (which are really just a tightly coupled SoC) I don't want separate
>>> drivers all having their own init, suspend/resume paths in them as I
>>> know we'll have to start making special vtable entry points etc to
>>> solve some random ordering issues that crop up.
>>
>> The DRM device has to be initialized/suspended/resumed as a whole, no
>> doubt about that. If that's not the case you indeed open up the door for
>> all kinds of ordering issues.
>>
>> Still the different components can be multiple devices, just initialize
>> the drm device once all components are probed. Remove it again once a
>> component is removed. Handle suspend in the DRM device, not in
>> the individual component drivers. The suspend in the component drivers
>> would only be called after the DRM device is completely quiesced.
>> Similarly the resume in the component drivers would not reenable the
>> components, this instead would be done in the DRM device when all
>> components are there again.
>
> But why? why should we have separate drivers for each component of a
> tightly coupled SoC?
>
> it makes no sense, having a driver node per every block in the chip
> isn't an advantage, it complicates
> things for no advantage at all. If we don't have hotplug hw removing
> one device shouldn't be possible
> this idea that removing a sub-driver should teardown the drm is crazy as well.
>
>>
>> This way all components could be proper (driver model)devices with
>> proper drivers without DRM even noticing that multiple components are
>> involved.
>>
>> Side note: We have no choice anyway. All SoCs can (sometimes must)
>> be extended with external I2C devices. On every SoC the I2C bus master
>> is a separate device, so we have a multicomponent device (in the sense
>> of driver model) already in many cases.
>>
>
> Having off-chip i2c devices being part of the driver model is fine,
> stuff works like that everywhere,
> having each SoC block part of the device model isn't fine unless you
> can really prove re-use and
> why having separate driver templating for each block is helpful.
>
> I'm not willing to have overly generic sub drivers that provide no
> advantage and only add lots
> of disadvantage like init and suspend/resume ordering. I know there is
> going to be SoC ordering
> issues at init time that will end up circular between two separate
> drivers each deferring because
> they want another driver up. Don't dig us into that hole, i2c has a
> well defined ordering of init,
> I don't think internal SoC devices are so well defined.
>
It seems that the main reason we should go to a single drm driver is
the probe ordering issue of sub drivers and the power ordering issue
of them.
First, I'd like to ask qustions to myself and other people. Do we
really need to define the display pipeline node? Is there really any
good way to can use only existing device nodes?
Please suppose the below things,
1. crtc and encoder/connector can be created when KMS driver and
display driver are probed regardless of the ordering
2. A crtc and a connector are connected when last one is created. This
means that a framebuffer will be created and the framebuffer's image
will be transferred to display via KMS driver.
And let see how hardware pipe lines can be linked each other,
1. Top level
CRTC -------- Encoder ---------- Connector
2. CRTC
Display controller or HDMI
Display controller or HDMI ---------- Image Enhancement chips or other
3. Encoder/Connector
LCD Panel
Display bus(mipi, dp) ------- LCD panel or TV
Display bus(mipi, dp) ------- bridge device(lvds) ------- LCD panel or TV
As you can see the above, if a crtc and a connector could be connected
each other regardless of the probe order - actually possible, and we
are already using this way in internal project - then I think it's
enough to consider display pipeline node to CRTC, and to
Encoder/Connector individually. DT binding of CRTC including Image
Enhancement chips can be done at top level of drm driver, and DT
binding of Encoder/Connector including bridge device and panel can be
done at probe of separated encoder/connector driver. Of course, for
avoiding power ordering issue, each encoder/connector drivers
shouldn't have their resume/suspend interfaces, and their pm should be
handled by dpms callback at top level of drm driver.
This way I think we could simplify to compose the display pipeline
node as device tree,and also we could have a separated device driver
as driver model.
Thanks,
Inki Dae
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2] efifb: prevent null-deref when iterating dmi_list
From: David Herrmann @ 2013-11-01 12:09 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-fbdev@vger.kernel.org, James Bates, linux-kernel,
Tomi Valkeinen, James Bates
In-Reply-To: <20131101111020.GD18477@ns203013.ovh.net>
Hi
On Fri, Nov 1, 2013 at 12:10 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 17:17 Thu 31 Oct , David Herrmann wrote:
>> Hi
>>
>> On Thu, Oct 31, 2013 at 11:45 AM, Jean-Christophe PLAGNIOL-VILLARD
>> <plagnioj@jcrosoft.com> wrote:
>> > On 18:40 Wed 02 Oct , David Herrmann wrote:
>> >> The dmi_list array is initialized using gnu designated initializers, and
>> >> therefore may contain fewer explicitly defined entries as there are
>> >> elements in it. This is because the enum above with M_xyz constants
>> >> contains more items than the designated initializer. Those elements not
>> >> explicitly initialized are implicitly set to 0.
>> >>
>> >> Now efifb_setup() loops through all these array elements, and performs
>> >> a strcmp on each item. For non explicitly initialized elements this will
>> >> be a null pointer:
>> >>
>> >> This patch swaps the check order in the if statement, thus checks first
>> >> whether dmi_list[i].base is null.
>> >>
>> >> Signed-off-by: James Bates <james.h.bates@yahoo.com>
>> >> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>> >
>> > with the simpleDRM arriving next merge I'm wondering if we need to keep it?
>>
>> SimpleDRM is not coming next merge-window. It's basically finished,
>> but I'm still working on the user-space side as its KMS api is highly
>> reduced compared to fully-featured DRM/KMS drivers. Maybe 3.13 will
>> work out.
>
> do you have a git tree for the simpleDRM that I can pull?
Sure, I usually push it to my fdo tree:
http://cgit.freedesktop.org/~dvdhrm/linux/log/?h=simpledrm
But note that you shouldn't be using it right now. User-space fails on
it as SimpleDRM only provides a single KMS-FB. It also needs to be
adjusted to the new x86-sysfb changes and I am reworking the handover
to real drivers.
Cheers
David
^ permalink raw reply
* Re: [PATCH v2] efifb: prevent null-deref when iterating dmi_list
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-11-01 11:10 UTC (permalink / raw)
To: David Herrmann
Cc: linux-fbdev@vger.kernel.org, James Bates, linux-kernel,
Tomi Valkeinen, James Bates
In-Reply-To: <CANq1E4QAwOG8Vdw2nCb8+LirZ278w58j+wpieeKvnNepga+baw@mail.gmail.com>
On 17:17 Thu 31 Oct , David Herrmann wrote:
> Hi
>
> On Thu, Oct 31, 2013 at 11:45 AM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 18:40 Wed 02 Oct , David Herrmann wrote:
> >> The dmi_list array is initialized using gnu designated initializers, and
> >> therefore may contain fewer explicitly defined entries as there are
> >> elements in it. This is because the enum above with M_xyz constants
> >> contains more items than the designated initializer. Those elements not
> >> explicitly initialized are implicitly set to 0.
> >>
> >> Now efifb_setup() loops through all these array elements, and performs
> >> a strcmp on each item. For non explicitly initialized elements this will
> >> be a null pointer:
> >>
> >> This patch swaps the check order in the if statement, thus checks first
> >> whether dmi_list[i].base is null.
> >>
> >> Signed-off-by: James Bates <james.h.bates@yahoo.com>
> >> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> >
> > with the simpleDRM arriving next merge I'm wondering if we need to keep it?
>
> SimpleDRM is not coming next merge-window. It's basically finished,
> but I'm still working on the user-space side as its KMS api is highly
> reduced compared to fully-featured DRM/KMS drivers. Maybe 3.13 will
> work out.
do you have a git tree for the simpleDRM that I can pull?
>
> Anyhow, this patch is still needed as it fixes a serious bug for simplefb.
ok
>
> Thanks
> David
^ permalink raw reply
* Re: outcome of DRM/KMS DT bindings session
From: Thierry Reding @ 2013-11-01 9:12 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel, ksummit-2013-discuss, Linux Fbdev development list
In-Reply-To: <CAPM=9ty7+A=YjSbRLxmo9mXSQSkZsZngBvTsryZ8+tHppEMPyw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]
On Fri, Nov 01, 2013 at 10:10:41AM +1000, Dave Airlie wrote:
> >> After looking at some of the ordering issues we've had with x86 GPUs
> >> (which are really just a tightly coupled SoC) I don't want separate
> >> drivers all having their own init, suspend/resume paths in them as I
> >> know we'll have to start making special vtable entry points etc to
> >> solve some random ordering issues that crop up.
> >
> > The DRM device has to be initialized/suspended/resumed as a whole, no
> > doubt about that. If that's not the case you indeed open up the door for
> > all kinds of ordering issues.
> >
> > Still the different components can be multiple devices, just initialize
> > the drm device once all components are probed. Remove it again once a
> > component is removed. Handle suspend in the DRM device, not in
> > the individual component drivers. The suspend in the component drivers
> > would only be called after the DRM device is completely quiesced.
> > Similarly the resume in the component drivers would not reenable the
> > components, this instead would be done in the DRM device when all
> > components are there again.
>
> But why? why should we have separate drivers for each component of a
> tightly coupled SoC?
>
> it makes no sense, having a driver node per every block in the chip
> isn't an advantage, it complicates
> things for no advantage at all. If we don't have hotplug hw removing
> one device shouldn't be possible
> this idea that removing a sub-driver should teardown the drm is crazy as well.
In my opinion separating things out into separate drivers makes it less
complicated. For instance it makes it very easy to manage the various
resources used by each driver (registers, interrupts, ...).
The only added complexity lies in the fact that we need some code to
synchronize the DRM device setup and teardown (and suspend and resume
for that matter). It's been discussed elsewhere that most SoCs are very
similar in their requirements, so I think we should be able to come up
with a piece of code that can be shared between drivers. Perhaps it
would even be possible to share that code between subsystems, since ALSA
and V4L2 may have similar requirements.
That's effectively not very different from what you're proposing. As far
as I can tell the only difference would be that this works in sort of a
"bottom-up" fashion, whereas your proposal would be "top-down".
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv9][ 1/6] video: imxfb: Introduce regulator support.
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-11-01 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383210928-18906-1-git-send-email-denis@eukrea.com>
On 10:15 Thu 31 Oct , Denis Carikli wrote:
> This commit is based on the following commit by Fabio Estevam:
> 4344429 video: mxsfb: Introduce regulator support
>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Eric Bénard <eric@eukrea.com>
> Signed-off-by: Denis Carikli <denis@eukrea.com>
> ---
next time you need to add a patch 0/3 with the description and ALL the history
of the different change between version so we can follow
Best Regards,
J.
> ChangeLog v8->v9:
> - return an error if regulator_{enable,disable} fails in
> imxfb_{enable,disable}_controller, and use it.
> ---
> drivers/video/imxfb.c | 53 ++++++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 41 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index 44ee678..322b358 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -28,6 +28,7 @@
> #include <linux/cpufreq.h>
> #include <linux/clk.h>
> #include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> #include <linux/dma-mapping.h>
> #include <linux/io.h>
> #include <linux/math64.h>
> @@ -145,6 +146,7 @@ struct imxfb_info {
> struct clk *clk_ipg;
> struct clk *clk_ahb;
> struct clk *clk_per;
> + struct regulator *reg_lcd;
> enum imxfb_type devtype;
> bool enabled;
>
> @@ -561,14 +563,25 @@ static void imxfb_exit_backlight(struct imxfb_info *fbi)
> }
> #endif
>
> -static void imxfb_enable_controller(struct imxfb_info *fbi)
> +static int imxfb_enable_controller(struct imxfb_info *fbi)
> {
> + int ret;
>
> if (fbi->enabled)
> - return;
> + return 0;
>
> pr_debug("Enabling LCD controller\n");
>
> + if (fbi->reg_lcd) {
> + ret = regulator_enable(fbi->reg_lcd);
> + if (ret) {
> + dev_err(&fbi->pdev->dev,
> + "lcd regulator enable failed with error: %d\n",
> + ret);
> + return ret;
> + }
> + }
> +
> writel(fbi->screen_dma, fbi->regs + LCDC_SSA);
>
> /* panning offset 0 (0 pixel offset) */
> @@ -593,12 +606,16 @@ static void imxfb_enable_controller(struct imxfb_info *fbi)
> fbi->backlight_power(1);
> if (fbi->lcd_power)
> fbi->lcd_power(1);
> +
> + return 0;
> }
>
> -static void imxfb_disable_controller(struct imxfb_info *fbi)
> +static int imxfb_disable_controller(struct imxfb_info *fbi)
> {
> + int ret;
> +
> if (!fbi->enabled)
> - return;
> + return 0;
>
> pr_debug("Disabling LCD controller\n");
>
> @@ -613,6 +630,15 @@ static void imxfb_disable_controller(struct imxfb_info *fbi)
> fbi->enabled = false;
>
> writel(0, fbi->regs + LCDC_RMCR);
> +
> + if (fbi->reg_lcd) {
> + ret = regulator_disable(fbi->reg_lcd);
> + if (ret)
> + dev_err(&fbi->pdev->dev,
> + "lcd regulator disable failed with error: %d\n",
> + ret);
> + return ret;
> + }
> }
>
> static int imxfb_blank(int blank, struct fb_info *info)
> @@ -626,13 +652,12 @@ static int imxfb_blank(int blank, struct fb_info *info)
> case FB_BLANK_VSYNC_SUSPEND:
> case FB_BLANK_HSYNC_SUSPEND:
> case FB_BLANK_NORMAL:
> - imxfb_disable_controller(fbi);
> - break;
> + return imxfb_disable_controller(fbi);
>
> case FB_BLANK_UNBLANK:
> - imxfb_enable_controller(fbi);
> - break;
> + return imxfb_enable_controller(fbi);
> }
> +
> return 0;
> }
>
> @@ -734,8 +759,7 @@ static int imxfb_suspend(struct platform_device *dev, pm_message_t state)
>
> pr_debug("%s\n", __func__);
>
> - imxfb_disable_controller(fbi);
> - return 0;
> + return imxfb_disable_controller(fbi);
> }
>
> static int imxfb_resume(struct platform_device *dev)
> @@ -745,8 +769,7 @@ static int imxfb_resume(struct platform_device *dev)
>
> pr_debug("%s\n", __func__);
>
> - imxfb_enable_controller(fbi);
> - return 0;
> + return imxfb_enable_controller(fbi);
> }
> #else
> #define imxfb_suspend NULL
> @@ -1020,6 +1043,12 @@ static int imxfb_probe(struct platform_device *pdev)
> goto failed_register;
> }
>
> + fbi->reg_lcd = devm_regulator_get(&pdev->dev, "lcd");
> + if (IS_ERR(fbi->reg_lcd)) {
> + dev_info(&pdev->dev, "No lcd regulator used.\n");
> + fbi->reg_lcd = NULL;
> + }
> +
> imxfb_enable_controller(fbi);
> fbi->pdev = pdev;
> #ifdef PWMR_BACKLIGHT_AVAILABLE
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: outcome of DRM/KMS DT bindings session
From: Mark Brown @ 2013-11-01 0:32 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel, ksummit-2013-discuss, Linux Fbdev development list
In-Reply-To: <CAPM=9ty7+A=YjSbRLxmo9mXSQSkZsZngBvTsryZ8+tHppEMPyw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]
On Fri, Nov 01, 2013 at 10:10:41AM +1000, Dave Airlie wrote:
> > Still the different components can be multiple devices, just initialize
> > the drm device once all components are probed. Remove it again once a
> But why? why should we have separate drivers for each component of a
> tightly coupled SoC?
> it makes no sense, having a driver node per every block in the chip
> isn't an advantage, it complicates
> things for no advantage at all. If we don't have hotplug hw removing
> one device shouldn't be possible
> this idea that removing a sub-driver should teardown the drm is crazy as well.
One case where this may be required is for integration with SoC power
domains where the DRM components are split between multiple domains (and
it may be more idiomatic even if they aren't). If the SoC is using
power domains then it will expect to see at least one device within each
domain that gets used to reference count the activity for the domain.
This could just be a composite device per domain though.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: outcome of DRM/KMS DT bindings session
From: Dave Airlie @ 2013-11-01 0:10 UTC (permalink / raw)
To: Sascha Hauer
Cc: ksummit-2013-discuss, Linux Fbdev development list, dri-devel
In-Reply-To: <20131030120229.GF24559@pengutronix.de>
>> After looking at some of the ordering issues we've had with x86 GPUs
>> (which are really just a tightly coupled SoC) I don't want separate
>> drivers all having their own init, suspend/resume paths in them as I
>> know we'll have to start making special vtable entry points etc to
>> solve some random ordering issues that crop up.
>
> The DRM device has to be initialized/suspended/resumed as a whole, no
> doubt about that. If that's not the case you indeed open up the door for
> all kinds of ordering issues.
>
> Still the different components can be multiple devices, just initialize
> the drm device once all components are probed. Remove it again once a
> component is removed. Handle suspend in the DRM device, not in
> the individual component drivers. The suspend in the component drivers
> would only be called after the DRM device is completely quiesced.
> Similarly the resume in the component drivers would not reenable the
> components, this instead would be done in the DRM device when all
> components are there again.
But why? why should we have separate drivers for each component of a
tightly coupled SoC?
it makes no sense, having a driver node per every block in the chip
isn't an advantage, it complicates
things for no advantage at all. If we don't have hotplug hw removing
one device shouldn't be possible
this idea that removing a sub-driver should teardown the drm is crazy as well.
>
> This way all components could be proper (driver model)devices with
> proper drivers without DRM even noticing that multiple components are
> involved.
>
> Side note: We have no choice anyway. All SoCs can (sometimes must)
> be extended with external I2C devices. On every SoC the I2C bus master
> is a separate device, so we have a multicomponent device (in the sense
> of driver model) already in many cases.
>
Having off-chip i2c devices being part of the driver model is fine,
stuff works like that everywhere,
having each SoC block part of the device model isn't fine unless you
can really prove re-use and
why having separate driver templating for each block is helpful.
I'm not willing to have overly generic sub drivers that provide no
advantage and only add lots
of disadvantage like init and suspend/resume ordering. I know there is
going to be SoC ordering
issues at init time that will end up circular between two separate
drivers each deferring because
they want another driver up. Don't dig us into that hole, i2c has a
well defined ordering of init,
I don't think internal SoC devices are so well defined.
Dave.
^ permalink raw reply
* Re: [PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
From: Tomasz Figa @ 2013-11-01 0:01 UTC (permalink / raw)
To: Jingoo Han
Cc: linux-fbdev, linux-samsung-soc, dri-devel,
'Tomi Valkeinen', marcheu,
'Jean-Christophe PLAGNIOL-VILLARD'
In-Reply-To: <003801ced694$a3342310$e99c6930$%han@samsung.com>
On Friday 01 of November 2013 08:55:12 Jingoo Han wrote:
> On Friday, November 01, 2013 8:27 AM, Tomasz Figa wrote:
> > On Friday 01 of November 2013 08:23:59 Jingoo Han wrote:
> > > On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote:
> > > > On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
> > > > > On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
> > > > > > CCing Jingoo,
> > > > > >
> > > > > > Is that ok to remove eDP driver from video/exynos? Isn't this
> > > > > > driver
> > > > > > really used by Linux framebuffer driver, s3c-fb.c?
> > > > >
> > > > > +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
> > > > >
> > > > > linux-fbdev list, linux-samsung-soc list
> > > > >
> > > > > Yes, it is used by s3c-fb.c.
> > > > >
> > > > > > Of course, now s3c-fb driver is dead code because this driver
> > > > > > doesn't
> > > > > > support device tree yet but we would need more reviews and
> > > > > > discussions
> > > > > > about moving this driver into drm side. Let's watch new rules
> > > > > > for
> > > > > > device tree bindings of DRM world. So I'd not like to merge
> > > > > > this
> > > > > > driver yet.
> > > > >
> > > > > 's3c-fb' driver is still used for other mass products projects.
> > > > > Just, device tree support patch is not yet submitted.
> > > >
> > > > Current in-tree users of s3c-fb drivers are s3c2443, non-DT
> > > > s3c64xx
> > > > and
> > > > all s5p* SoCs. It is not used on Exynos SoCs anymore.
> > >
> > > Hi Tomasz Figa,
> >
> > Just Tomasz. ;)
>
> Hi Tomasz, :-)
>
> > > Some mass product projects using Exynos5250 and etc, use s3c-fb
> > > driver
> > > and dp driver. Also, these projects are still using Framebuffer, not
> > > DRM.
> >
> > Well, those are based on vendor trees anyway, so do not really affect
> > mainline kernel.
>
> OK, I see.
>
> > > > As for Exynos DP driver, what SoCs does it support? If only Exynos
> > > > (as
> > > > the name suggests) then there is no point in keeping it at
> > > > video/exynos and making it a part of Exynos DRM driver seems
> > > > reasonable to me.
> > >
> > > However, when considering only mainline kernel, I have no strong
> > > objection. As you know, many Linux kernel based OS projects using
> > > Exynos, are using DRM, not Framebuffer.
> >
> > Generally, fbdev is strongly discouraged in any new systems and DRM is
> > the way to go, so I don't think we should ever want to bring s3c-fb
> > support back to Exynos platforms.
>
> Yes, you're right.
> Personally, I think that all Exynos platforms should go into DRM, not
> FB.
>
> One more thing, then how about moving Exynos MIPI to DRM side?
> Is there any plan on Exynos MIPI?
Well, it will eventually have to be moved somewhere else than it is, but I
believe this will have to wait for Common Display Framework.
This is because the case of MIPI DSI is slightly different from
DisplayPort, since it is not an enumerable/auto-configurable interface and
requires dedicated panel drivers and static data provided by board
designers (in DT for example). Handling of such things in a generic way
will be done by CDF.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
From: Jingoo Han @ 2013-10-31 23:55 UTC (permalink / raw)
To: 'Tomasz Figa'
Cc: 'Inki Dae', 'Sean Paul', dri-devel,
'Tomi Valkeinen',
'Jean-Christophe PLAGNIOL-VILLARD', linux-fbdev,
linux-samsung-soc, airlied, marcheu, 'Jingoo Han'
In-Reply-To: <10329504.DMev7iL3eL@flatron>
On Friday, November 01, 2013 8:27 AM, Tomasz Figa wrote:
> On Friday 01 of November 2013 08:23:59 Jingoo Han wrote:
> > On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote:
> > > On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
> > > > On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
> > > > > CCing Jingoo,
> > > > >
> > > > > Is that ok to remove eDP driver from video/exynos? Isn't this
> > > > > driver
> > > > > really used by Linux framebuffer driver, s3c-fb.c?
> > > >
> > > > +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
> > > >
> > > > linux-fbdev list, linux-samsung-soc list
> > > >
> > > > Yes, it is used by s3c-fb.c.
> > > >
> > > > > Of course, now s3c-fb driver is dead code because this driver
> > > > > doesn't
> > > > > support device tree yet but we would need more reviews and
> > > > > discussions
> > > > > about moving this driver into drm side. Let's watch new rules for
> > > > > device tree bindings of DRM world. So I'd not like to merge this
> > > > > driver yet.
> > > >
> > > > 's3c-fb' driver is still used for other mass products projects.
> > > > Just, device tree support patch is not yet submitted.
> > >
> > > Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx
> > > and
> > > all s5p* SoCs. It is not used on Exynos SoCs anymore.
> >
> > Hi Tomasz Figa,
>
> Just Tomasz. ;)
Hi Tomasz, :-)
>
> > Some mass product projects using Exynos5250 and etc, use s3c-fb driver
> > and dp driver. Also, these projects are still using Framebuffer, not
> > DRM.
>
> Well, those are based on vendor trees anyway, so do not really affect
> mainline kernel.
OK, I see.
>
> > > As for Exynos DP driver, what SoCs does it support? If only Exynos (as
> > > the name suggests) then there is no point in keeping it at
> > > video/exynos and making it a part of Exynos DRM driver seems
> > > reasonable to me.
> >
> > However, when considering only mainline kernel, I have no strong
> > objection. As you know, many Linux kernel based OS projects using
> > Exynos, are using DRM, not Framebuffer.
>
> Generally, fbdev is strongly discouraged in any new systems and DRM is the
> way to go, so I don't think we should ever want to bring s3c-fb support
> back to Exynos platforms.
Yes, you're right.
Personally, I think that all Exynos platforms should go into DRM, not FB.
One more thing, then how about moving Exynos MIPI to DRM side?
Is there any plan on Exynos MIPI?
Best regards,
Jingoo Han
>
> >
> > Also, if moving DP driver to DRM, MAINTAINERS entry for Exynos DP driver
> > should be updated, too.
>
> That's correct.
^ permalink raw reply
* Re: [PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
From: Tomasz Figa @ 2013-10-31 23:27 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Inki Dae', 'Sean Paul', dri-devel,
'Tomi Valkeinen',
'Jean-Christophe PLAGNIOL-VILLARD', linux-fbdev,
linux-samsung-soc, airlied, marcheu
In-Reply-To: <000801ced690$47480520$d5d80f60$%han@samsung.com>
On Friday 01 of November 2013 08:23:59 Jingoo Han wrote:
> On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote:
> > On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
> > > On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
> > > > CCing Jingoo,
> > > >
> > > > Is that ok to remove eDP driver from video/exynos? Isn't this
> > > > driver
> > > > really used by Linux framebuffer driver, s3c-fb.c?
> > >
> > > +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
> > >
> > > linux-fbdev list, linux-samsung-soc list
> > >
> > > Yes, it is used by s3c-fb.c.
> > >
> > > > Of course, now s3c-fb driver is dead code because this driver
> > > > doesn't
> > > > support device tree yet but we would need more reviews and
> > > > discussions
> > > > about moving this driver into drm side. Let's watch new rules for
> > > > device tree bindings of DRM world. So I'd not like to merge this
> > > > driver yet.
> > >
> > > 's3c-fb' driver is still used for other mass products projects.
> > > Just, device tree support patch is not yet submitted.
> >
> > Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx
> > and
> > all s5p* SoCs. It is not used on Exynos SoCs anymore.
>
> Hi Tomasz Figa,
Just Tomasz. ;)
> Some mass product projects using Exynos5250 and etc, use s3c-fb driver
> and dp driver. Also, these projects are still using Framebuffer, not
> DRM.
Well, those are based on vendor trees anyway, so do not really affect
mainline kernel.
> > As for Exynos DP driver, what SoCs does it support? If only Exynos (as
> > the name suggests) then there is no point in keeping it at
> > video/exynos and making it a part of Exynos DRM driver seems
> > reasonable to me.
>
> However, when considering only mainline kernel, I have no strong
> objection. As you know, many Linux kernel based OS projects using
> Exynos, are using DRM, not Framebuffer.
Generally, fbdev is strongly discouraged in any new systems and DRM is the
way to go, so I don't think we should ever want to bring s3c-fb support
back to Exynos platforms.
>
> Also, if moving DP driver to DRM, MAINTAINERS entry for Exynos DP driver
> should be updated, too.
That's correct.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
From: Jingoo Han @ 2013-10-31 23:23 UTC (permalink / raw)
To: 'Tomasz Figa'
Cc: 'Inki Dae', 'Sean Paul', dri-devel,
'Tomi Valkeinen',
'Jean-Christophe PLAGNIOL-VILLARD', linux-fbdev,
linux-samsung-soc, airlied, marcheu, 'Jingoo Han'
In-Reply-To: <1598437.V5FBHdEq6k@flatron>
On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote:
> On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
> > On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
> > > CCing Jingoo,
> > >
> > > Is that ok to remove eDP driver from video/exynos? Isn't this driver
> > > really used by Linux framebuffer driver, s3c-fb.c?
> >
> > +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
> > linux-fbdev list, linux-samsung-soc list
> >
> > Yes, it is used by s3c-fb.c.
> >
> > > Of course, now s3c-fb driver is dead code because this driver doesn't
> > > support device tree yet but we would need more reviews and discussions
> > > about moving this driver into drm side. Let's watch new rules for
> > > device tree bindings of DRM world. So I'd not like to merge this
> > > driver yet.
> > 's3c-fb' driver is still used for other mass products projects.
> > Just, device tree support patch is not yet submitted.
>
> Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx and
> all s5p* SoCs. It is not used on Exynos SoCs anymore.
Hi Tomasz Figa,
Some mass product projects using Exynos5250 and etc, use s3c-fb driver
and dp driver. Also, these projects are still using Framebuffer, not DRM.
>
> As for Exynos DP driver, what SoCs does it support? If only Exynos (as the
> name suggests) then there is no point in keeping it at video/exynos and
> making it a part of Exynos DRM driver seems reasonable to me.
However, when considering only mainline kernel, I have no strong objection.
As you know, many Linux kernel based OS projects using Exynos, are using
DRM, not Framebuffer.
Also, if moving DP driver to DRM, MAINTAINERS entry for Exynos DP driver
should be updated, too.
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
From: Tomasz Figa @ 2013-10-31 23:11 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Inki Dae', 'Sean Paul', dri-devel,
'Tomi Valkeinen',
'Jean-Christophe PLAGNIOL-VILLARD', linux-fbdev,
linux-samsung-soc, airlied, marcheu
In-Reply-To: <000701ced68d$c3cd7d80$4b687880$%han@samsung.com>
On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
> On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
> > CCing Jingoo,
> >
> > Is that ok to remove eDP driver from video/exynos? Isn't this driver
> > really used by Linux framebuffer driver, s3c-fb.c?
>
> +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
> linux-fbdev list, linux-samsung-soc list
>
> Yes, it is used by s3c-fb.c.
>
> > Of course, now s3c-fb driver is dead code because this driver doesn't
> > support device tree yet but we would need more reviews and discussions
> > about moving this driver into drm side. Let's watch new rules for
> > device tree bindings of DRM world. So I'd not like to merge this
> > driver yet.
> 's3c-fb' driver is still used for other mass products projects.
> Just, device tree support patch is not yet submitted.
Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx and
all s5p* SoCs. It is not used on Exynos SoCs anymore.
As for Exynos DP driver, what SoCs does it support? If only Exynos (as the
name suggests) then there is no point in keeping it at video/exynos and
making it a part of Exynos DRM driver seems reasonable to me.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
From: Jingoo Han @ 2013-10-31 23:06 UTC (permalink / raw)
To: 'Inki Dae', 'Sean Paul', dri-devel
Cc: 'Tomi Valkeinen',
'Jean-Christophe PLAGNIOL-VILLARD', linux-fbdev,
linux-samsung-soc, airlied, tomasz.figa, marcheu,
'Jingoo Han'
In-Reply-To: <031801ced626$7cca5820$765f0860$%dae@samsung.com>
On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
>
> CCing Jingoo,
>
> Is that ok to remove eDP driver from video/exynos? Isn't this driver really
> used by Linux framebuffer driver, s3c-fb.c?
+cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
linux-fbdev list, linux-samsung-soc list
Yes, it is used by s3c-fb.c.
>
> Of course, now s3c-fb driver is dead code because this driver doesn't
> support device tree yet but we would need more reviews and discussions about
> moving this driver into drm side. Let's watch new rules for device tree
> bindings of DRM world. So I'd not like to merge this driver yet.
's3c-fb' driver is still used for other mass products projects.
Just, device tree support patch is not yet submitted.
Sean Paul,
When moving the driver, notify related Maintainers of that driver.
Please use 'scripts/get_maintainer.pl' next time.
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH v2 19/19] fbdev: sh-mobile-lcdcfb: Enable the driver on all ARM platforms
From: Geert Uytterhoeven @ 2013-10-31 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383086274-11049-20-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent,
On Tue, 29 Oct 2013, Laurent Pinchart wrote:
> Renesas ARM platforms are transitioning from single-platform to
> multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
> driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
> and ARCH_SHMOBILE_MULTI, and increase build testing coverage with
> COMPILE_TEST.
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 84b685f..32b5c86 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2482,7 +2482,7 @@ endif
>
> config FB_SH_MOBILE_MERAM
> tristate "SuperH Mobile MERAM read ahead support"
> - depends on (SUPERH || ARCH_SHMOBILE)
> + depends on (SUPERH || ARM || COMPILE_TEST)
> select GENERIC_ALLOCATOR
> ---help---
> Enable MERAM support for the SuperH controller.
While the below compiler warnings have been seen with sh-randconfig
before, they're more likely to happen with COMPILE_TEST=y.
I now see them with e.g. m68k-allmodconfig, so I created a patch.
From 15eb69172457c675cde177a6f742b6f1dabdeb18 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Thu, 31 Oct 2013 20:35:14 +0100
Subject: [PATCH] fbdev: sh_mobile_meram: Fix defined but not used compiler
warnings
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If CONFIG_PM_SLEEP resp. CONFIG_PM_RUNTIME are not set:
drivers/video/sh_mobile_meram.c:573: warning: ¡sh_mobile_meram_suspend¢ defined but not used
drivers/video/sh_mobile_meram.c:597: warning: ¡sh_mobile_meram_resume¢ defined but not used
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/video/sh_mobile_meram.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index e0f098562a74..56a8e47ffceb 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -569,6 +569,7 @@ EXPORT_SYMBOL_GPL(sh_mobile_meram_cache_update);
* Power management
*/
+#ifdef CONFIG_PM_SLEEP
static int sh_mobile_meram_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -592,7 +593,9 @@ static int sh_mobile_meram_suspend(struct device *dev)
}
return 0;
}
+#endif
+#ifdef CONFIG_PM_RUNTIME
static int sh_mobile_meram_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -611,6 +614,7 @@ static int sh_mobile_meram_resume(struct device *dev)
meram_write_reg(priv->base, common_regs[i], priv->regs[i]);
return 0;
}
+#endif
static UNIVERSAL_DEV_PM_OPS(sh_mobile_meram_dev_pm_ops,
sh_mobile_meram_suspend,
--
1.7.9.5
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
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