[PATCH v5 00/11] imx-drm dt bindings
Hi, this latest version of the imx-drm DT binding patches applies on top of staging-next and also depends on the OF graph binding patchset that moves the v4l2_of helpers to drivers/of. Currently, the two patchsets are also available at: git://git.pengutronix.de/git/pza/linux.git topic/of-graph git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt I have added device tree bindings between IPU and the encoders as documented in Documentation/devicetree/bindings/graph.txt and used those to determine the possible_crtcs and mux_id, and to find all necessary components that hang off of the display interface ports. This allows to move the imx-drm node into the SoC level dtsi. The existing i.MX51 and i.MX53 device trees are updated and device tree binding documentation is included. Changes since v4: - Changed DT compatible string to 'fsl,imx-display-subsystem' instead of Linux specific 'fsl,imx-drm' - Changed DT node name from 'imx-drm' to 'display-subsystem' - Fixed copy&paste documentation error and added optional 'ddc-i2c-bus' property in HDMI binding documentation - Fixed imx-tve and imx-hdmi to use the common 'ddc-i2c-bus' property as already used by the simple-panel binding instead of the custom but very generic 'ddc'. regards Philipp Philipp Zabel (11): staging: imx-drm-core: Use OF graph to find components and connections between encoder and crtcs staging: imx-drm-core: use of_graph_parse_endpoint staging: imx-drm: Document updated imx-drm device tree bindings staging: imx-drm: Document imx-hdmi device tree bindings imx-drm: imx-hdmi: Fix DDC I2C bus property imx-drm: imx-tve: Fix DDC I2C bus property ARM: dts: imx53-mba53: Fix TVE DDC I2C bus property ARM: dts: imx51: Add IPU ports and endpoints, move imx-drm node to dtsi ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi ARM: dts: imx6qdl: Add IPU DI ports and endpoints, move imx-drm node to dtsi staging: imx-drm: Update TODO .../bindings/staging/imx-drm/fsl-imx-drm.txt | 48 - .../devicetree/bindings/staging/imx-drm/hdmi.txt | 58 ++ .../devicetree/bindings/staging/imx-drm/ldb.txt| 20 +- arch/arm/boot/dts/imx51-apf51dev.dts | 11 +- arch/arm/boot/dts/imx51-babbage.dts| 28 ++- arch/arm/boot/dts/imx51.dtsi | 22 ++- arch/arm/boot/dts/imx53-m53evk.dts | 17 +- arch/arm/boot/dts/imx53-mba53.dts | 17 +- arch/arm/boot/dts/imx53-qsb.dts| 17 +- arch/arm/boot/dts/imx53.dtsi | 64 +- arch/arm/boot/dts/imx6dl.dtsi | 22 +-- arch/arm/boot/dts/imx6q-sabresd.dts| 4 - arch/arm/boot/dts/imx6q.dtsi | 124 +++- arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 6 - arch/arm/boot/dts/imx6qdl.dtsi | 128 +++- drivers/staging/imx-drm/TODO | 5 - drivers/staging/imx-drm/imx-drm-core.c | 217 +++-- drivers/staging/imx-drm/imx-drm.h | 5 +- drivers/staging/imx-drm/imx-hdmi.c | 4 +- drivers/staging/imx-drm/imx-ldb.c | 4 +- drivers/staging/imx-drm/imx-tve.c | 2 +- drivers/staging/imx-drm/ipuv3-crtc.c | 47 - 22 files changed, 712 insertions(+), 158 deletions(-) create mode 100644 Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt -- 1.9.0.rc3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote: > Hi, > > this latest version of the imx-drm DT binding patches applies > on top of staging-next and also depends on the OF graph binding > patchset that moves the v4l2_of helpers to drivers/of. > Currently, the two patchsets are also available at: > git://git.pengutronix.de/git/pza/linux.git topic/of-graph > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt Okay, having looked at the second tree, pulling that will result in pulling in all of the staging tree here, which I'd rather not do. Unless there's any objection, I'd like to take these as patches on top of the imx-drm stuff which I sent to Greg plus the of-graph stuff which they depend upon. In other words, exactly how I've been testing it today. Any objections? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote: > On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote: > > Hi, > > > > this latest version of the imx-drm DT binding patches applies > > on top of staging-next and also depends on the OF graph binding > > patchset that moves the v4l2_of helpers to drivers/of. > > Currently, the two patchsets are also available at: > > git://git.pengutronix.de/git/pza/linux.git topic/of-graph > > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt > > Okay, having looked at the second tree, pulling that will result in > pulling in all of the staging tree here, which I'd rather not do. Unless > there's any objection, I'd like to take these as patches on top of the > imx-drm stuff which I sent to Greg plus the of-graph stuff which they > depend upon. In other words, exactly how I've been testing it today. > > Any objections? None from me! :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
[Added Shawn to Cc:] On Fri, Mar 7, 2014 at 7:28 PM, Greg Kroah-Hartman wrote: > On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote: >> On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote: >> > Hi, >> > >> > this latest version of the imx-drm DT binding patches applies >> > on top of staging-next and also depends on the OF graph binding >> > patchset that moves the v4l2_of helpers to drivers/of. >> > Currently, the two patchsets are also available at: >> > git://git.pengutronix.de/git/pza/linux.git topic/of-graph >> > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt >> >> Okay, having looked at the second tree, pulling that will result in >> pulling in all of the staging tree here, which I'd rather not do. Unless >> there's any objection, I'd like to take these as patches on top of the >> imx-drm stuff which I sent to Greg plus the of-graph stuff which they >> depend upon. In other words, exactly how I've been testing it today. >> >> Any objections? > > None from me! :) Nor from me. But I'd like to point out that there already is one merge issue with Shawn's for-next branch in arch/arm/boot/dts/imx53-qsb.dts between d5eb195 "ARM: dts: i.MX53: move common QSB nodes to new file" and these two patches: 17b5001 "imx-drm: convert to componentised device support". "ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi" The first one already is in staging-next. regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
On Fri, Mar 07, 2014 at 07:57:51PM +0100, Philipp Zabel wrote: > [Added Shawn to Cc:] > > On Fri, Mar 7, 2014 at 7:28 PM, Greg Kroah-Hartman > wrote: > > On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote: > >> On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote: > >> > Hi, > >> > > >> > this latest version of the imx-drm DT binding patches applies > >> > on top of staging-next and also depends on the OF graph binding > >> > patchset that moves the v4l2_of helpers to drivers/of. > >> > Currently, the two patchsets are also available at: > >> > git://git.pengutronix.de/git/pza/linux.git topic/of-graph > >> > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt > >> > >> Okay, having looked at the second tree, pulling that will result in > >> pulling in all of the staging tree here, which I'd rather not do. Unless > >> there's any objection, I'd like to take these as patches on top of the > >> imx-drm stuff which I sent to Greg plus the of-graph stuff which they > >> depend upon. In other words, exactly how I've been testing it today. > >> > >> Any objections? > > > > None from me! :) > > Nor from me. But I'd like to point out that there already is one merge issue > with Shawn's for-next branch in arch/arm/boot/dts/imx53-qsb.dts between > d5eb195 "ARM: dts: i.MX53: move common QSB nodes to new file" > and these two patches: > 17b5001 "imx-drm: convert to componentised device support". > "ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to > dtsi" > The first one already is in staging-next. Yes, I'm aware of that (since I've been encountering it when creating the build tree for my autobuilder.) Thanks. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote: > Hi, > > this latest version of the imx-drm DT binding patches applies > on top of staging-next and also depends on the OF graph binding > patchset that moves the v4l2_of helpers to drivers/of. > Currently, the two patchsets are also available at: > git://git.pengutronix.de/git/pza/linux.git topic/of-graph > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt Hi Philipp, I just came across a couple problems when testing the series on my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it using Russell's branch below, which I believe has all the pieces put together. git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging - When I enable HDMI and LVDS support in both kernel build and device tree, HDMI seems working fine but LVDS color is corrupted quite badly. - When I enable HDMI and LVDS support in kernel build but only LVDS in device tree (keep HDMI disabled in device tree by not changing 'status' of HDMI node to 'okay'), LVDS does not even work. In this case, it seems that the binding of display-subsystem does not succeed. Please confirm if they are real problems or I'm missing something here. Shawn ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
Hi Shawn,
Am Dienstag, den 11.03.2014, 11:46 +0800 schrieb Shawn Guo:
> On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote:
> > Hi,
> >
> > this latest version of the imx-drm DT binding patches applies
> > on top of staging-next and also depends on the OF graph binding
> > patchset that moves the v4l2_of helpers to drivers/of.
> > Currently, the two patchsets are also available at:
> > git://git.pengutronix.de/git/pza/linux.git topic/of-graph
> > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt
>
> Hi Philipp,
>
> I just came across a couple problems when testing the series on
> my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it
> using Russell's branch below, which I believe has all the pieces put
> together.
>
> git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging
>
> - When I enable HDMI and LVDS support in both kernel build and device
> tree, HDMI seems working fine but LVDS color is corrupted quite badly.
>
> - When I enable HDMI and LVDS support in kernel build but only LVDS in
> device tree (keep HDMI disabled in device tree by not changing
> 'status' of HDMI node to 'okay'), LVDS does not even work. In this
> case, it seems that the binding of display-subsystem does not succeed.
Can you check if you get the bound messages from
drivers/base/component.c:
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops)
I have tried this branch with a Phytec phyFLEX i.MX6S on PBAB01
baseboard with EDT 800x480 LVDS panel, and it seems to work.
The check in drivers/staging/imx-drm/imx-drm-core.c:675 should make sure
that unavailable (status="disabled") devices are just skipped.
> Please confirm if they are real problems or I'm missing something here.
If the devices are bound, can you check in debugfs whether the panel
(ldb_di) clock is set correctly?
I wonder if Russell's DI code makes a decision that the panel clock
can't be supported from the IPU internal clock. Then you'd need
something like this to allow setting the video PLL:
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index f6c5af5..f9b90e7 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -258,14 +258,14 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[ipu2_sel] = imx_clk_mux("ipu2_sel", base + 0x3c,
14, 2, ipu_sels, ARRAY_SIZE(ipu_sels));
clk[ldb_di0_sel] = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c,
9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
clk[ldb_di1_sel] = imx_clk_mux_flags("ldb_di1_sel", base + 0x2c,
12, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
- clk[ipu1_di0_pre_sel] = imx_clk_mux("ipu1_di0_pre_sel", base + 0x34, 6,
3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels));
- clk[ipu1_di1_pre_sel] = imx_clk_mux("ipu1_di1_pre_sel", base + 0x34,
15, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels));
- clk[ipu2_di0_pre_sel] = imx_clk_mux("ipu2_di0_pre_sel", base + 0x38, 6,
3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels));
- clk[ipu2_di1_pre_sel] = imx_clk_mux("ipu2_di1_pre_sel", base + 0x38,
15, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels));
- clk[ipu1_di0_sel] = imx_clk_mux("ipu1_di0_sel", base + 0x34, 0,
3, ipu1_di0_sels, ARRAY_SIZE(ipu1_di0_sels));
- clk[ipu1_di1_sel] = imx_clk_mux("ipu1_di1_sel", base + 0x34, 9,
3, ipu1_di1_sels, ARRAY_SIZE(ipu1_di1_sels));
- clk[ipu2_di0_sel] = imx_clk_mux("ipu2_di0_sel", base + 0x38, 0,
3, ipu2_di0_sels, ARRAY_SIZE(ipu2_di0_sels));
- clk[ipu2_di1_sel] = imx_clk_mux("ipu2_di1_sel", base + 0x38, 9,
3, ipu2_di1_sels, ARRAY_SIZE(ipu2_di1_sels));
+ clk[ipu1_di0_pre_sel] = imx_clk_mux_flags("ipu1_di0_pre_sel", base +
0x34, 6, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels),
CLK_SET_RATE_PARENT);
+ clk[ipu1_di1_pre_sel] = imx_clk_mux_flags("ipu1_di1_pre_sel", base +
0x34, 15, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels),
CLK_SET_RATE_PARENT);
+ clk[ipu2_di0_pre_sel] = imx_clk_mux_flags("ipu2_di0_pre_sel", base +
0x38, 6, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels),
CLK_SET_RATE_PARENT);
+ clk[ipu2_di1_pre_sel] = imx_clk_mux_flags("ipu2_di1_pre_sel", base +
0x38, 15, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels),
CLK_SET_RATE_PARENT);
+ clk[ipu1_di0_sel] = imx_clk_mux_flags("ipu1_di0_sel", base +
0x34, 0, 3, ipu1_di0_sels, ARRAY_SIZE(ipu1_di0_sels), CLK_SET_RATE_PARENT);
+ clk[ipu1_di1_sel] = imx_clk_mux_flags("ipu1_di1_sel", base +
0x34, 9, 3, ipu1_di1_sels, ARRAY_SIZE(ipu1_di1_sels), CLK_SET_RATE_PARENT);
+ clk[ipu2_di0_sel] = imx_clk_mux_flags("ipu2_di0_sel", base +
0x3
Re: [PATCH v5 00/11] imx-drm dt bindings
On Tue, Mar 11, 2014 at 12:42:08PM +0100, Philipp Zabel wrote:
> Hi Shawn,
>
> Am Dienstag, den 11.03.2014, 11:46 +0800 schrieb Shawn Guo:
> > On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote:
> > > Hi,
> > >
> > > this latest version of the imx-drm DT binding patches applies
> > > on top of staging-next and also depends on the OF graph binding
> > > patchset that moves the v4l2_of helpers to drivers/of.
> > > Currently, the two patchsets are also available at:
> > > git://git.pengutronix.de/git/pza/linux.git topic/of-graph
> > > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt
> >
> > Hi Philipp,
> >
> > I just came across a couple problems when testing the series on
> > my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it
> > using Russell's branch below, which I believe has all the pieces put
> > together.
> >
> > git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging
> >
> > - When I enable HDMI and LVDS support in both kernel build and device
> > tree, HDMI seems working fine but LVDS color is corrupted quite badly.
> >
> > - When I enable HDMI and LVDS support in kernel build but only LVDS in
> > device tree (keep HDMI disabled in device tree by not changing
> > 'status' of HDMI node to 'okay'), LVDS does not even work. In this
> > case, it seems that the binding of display-subsystem does not succeed.
>
> Can you check if you get the bound messages from
> drivers/base/component.c:
>
> imx-drm display-subsystem.11: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
> imx-drm display-subsystem.11: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
> imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops)
>
> I have tried this branch with a Phytec phyFLEX i.MX6S on PBAB01
> baseboard with EDT 800x480 LVDS panel, and it seems to work.
> The check in drivers/staging/imx-drm/imx-drm-core.c:675 should make sure
> that unavailable (status="disabled") devices are just skipped.
Sorry, Philipp. The setup in my report is incorrect. The correct setup
to see this issue consists of:
1) build a kernel without HDMI support, i.e. !CONFIG_DRM_IMX_HDMI
2) enable HDMI device in DT, i.e. adding the lines below in board dts.
&hdmi {
status = "okay";
};
Sorry for the confusion.
Shawn
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
Am Dienstag, den 11.03.2014, 21:27 +0800 schrieb Shawn Guo:
> On Tue, Mar 11, 2014 at 12:42:08PM +0100, Philipp Zabel wrote:
> > Hi Shawn,
> >
> > Am Dienstag, den 11.03.2014, 11:46 +0800 schrieb Shawn Guo:
> > > On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote:
> > > > Hi,
> > > >
> > > > this latest version of the imx-drm DT binding patches applies
> > > > on top of staging-next and also depends on the OF graph binding
> > > > patchset that moves the v4l2_of helpers to drivers/of.
> > > > Currently, the two patchsets are also available at:
> > > > git://git.pengutronix.de/git/pza/linux.git topic/of-graph
> > > > git://git.pengutronix.de/git/pza/linux.git topic/imx-drm-dt
> > >
> > > Hi Philipp,
> > >
> > > I just came across a couple problems when testing the series on
> > > my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it
> > > using Russell's branch below, which I believe has all the pieces put
> > > together.
> > >
> > > git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging
> > >
> > > - When I enable HDMI and LVDS support in both kernel build and device
> > > tree, HDMI seems working fine but LVDS color is corrupted quite badly.
> > >
> > > - When I enable HDMI and LVDS support in kernel build but only LVDS in
> > > device tree (keep HDMI disabled in device tree by not changing
> > > 'status' of HDMI node to 'okay'), LVDS does not even work. In this
> > > case, it seems that the binding of display-subsystem does not succeed.
> >
> > Can you check if you get the bound messages from
> > drivers/base/component.c:
> >
> > imx-drm display-subsystem.11: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
> > imx-drm display-subsystem.11: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
> > imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops)
> >
> > I have tried this branch with a Phytec phyFLEX i.MX6S on PBAB01
> > baseboard with EDT 800x480 LVDS panel, and it seems to work.
> > The check in drivers/staging/imx-drm/imx-drm-core.c:675 should make sure
> > that unavailable (status="disabled") devices are just skipped.
>
> Sorry, Philipp. The setup in my report is incorrect. The correct setup
> to see this issue consists of:
>
> 1) build a kernel without HDMI support, i.e. !CONFIG_DRM_IMX_HDMI
>
> 2) enable HDMI device in DT, i.e. adding the lines below in board dts.
>
> &hdmi {
> status = "okay";
> };
>
> Sorry for the confusion.
>
This isn't a supported use-case, the componentized device stuff is there
exactly to ensure that the DRM device is only brought up after all
active components have an driver attached to them.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
On Tue, Mar 11, 2014 at 02:34:38PM +0100, Lucas Stach wrote:
> > Sorry, Philipp. The setup in my report is incorrect. The correct setup
> > to see this issue consists of:
> >
> > 1) build a kernel without HDMI support, i.e. !CONFIG_DRM_IMX_HDMI
> >
> > 2) enable HDMI device in DT, i.e. adding the lines below in board dts.
> >
> > &hdmi {
> >status = "okay";
> > };
> >
> > Sorry for the confusion.
> >
> This isn't a supported use-case, the componentized device stuff is there
> exactly to ensure that the DRM device is only brought up after all
> active components have an driver attached to them.
Ah, yes. I was in the impression that LVDS should still work in this
setup, but that was the case before Philipp's series. In Russell's
original imx-drm setup, LVDS still works even if I enable the HDMI
device in DT, as long as I do not reference it from 'connectors'.
imx_drm: imx-drm {
compatible = "fsl,imx-drm";
crtcs = <&ipu1 0>, <&ipu1 1>;
connectors = <&ldb>;
};
Thanks for the clarification.
Shawn
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote: > I just came across a couple problems when testing the series on > my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it > using Russell's branch below, which I believe has all the pieces put > together. > > git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging > > - When I enable HDMI and LVDS support in both kernel build and device > tree, HDMI seems working fine but LVDS color is corrupted quite badly. Philipp, Did you get any chance to reproduce this dual display issue? Now it shows on mainline kernel. And I see another HDMI regression with my testing on mainline kernel. I can have my HDMI work at 1920x1080 with v3.14 kernel, but it can only probes 1024x768 with the mainline today. The Xorg.0.log are attached below. The hardware and user space are same, so I guess this is another issue introduced by the recently kernel driver changes? Shawn mainline kernel === [20.606] (II) LoadModule: "modesetting" [20.607] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [20.609] (II) Module modesetting: vendor="X.Org Foundation" [20.609]compiled for 1.12.1.902, module version = 0.3.0 [20.610]Module class: X.Org Video Driver [20.610]ABI class: X.Org Video Driver, version 12.0 [20.610] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [20.610] (++) using VT number 7 [20.624] (WW) Falling back to old probe method for modesetting [20.624] (II) modesetting(0): using default device [20.627] (II) modesetting(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [20.627] (==) modesetting(0): Depth 24, (==) framebuffer bpp 32 [20.628] (==) modesetting(0): RGB weight 888 [20.628] (==) modesetting(0): Default visual is TrueColor [20.628] (II) modesetting(0): ShadowFB: preferred NO, enabled NO [20.628] (II) modesetting(0): Output HDMI-0 has no monitor section [20.629] (II) modesetting(0): EDID for output HDMI-0 [20.629] (II) modesetting(0): Printing probed modes for output HDMI-0 [20.629] (II) modesetting(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [20.629] (II) modesetting(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [20.629] (II) modesetting(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [20.630] (II) modesetting(0): Modeline "848x480"x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) [20.630] (II) modesetting(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 489 492 525 -hsync -vsync (31.5 kHz e) [20.630] (II) modesetting(0): Output HDMI-0 connected [20.630] (II) modesetting(0): Using exact sizes for initial modes [20.630] (II) modesetting(0): Output HDMI-0 using initial mode 1024x768 [20.630] (II) modesetting(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [20.630] (==) modesetting(0): DPI set to (96, 96) v3.14 kernel [20.214] (II) LoadModule: "modesetting" [20.215] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [20.217] (II) Module modesetting: vendor="X.Org Foundation" [20.217]compiled for 1.12.1.902, module version = 0.3.0 [20.217]Module class: X.Org Video Driver [20.217]ABI class: X.Org Video Driver, version 12.0 [20.217] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [20.217] (++) using VT number 7 [20.240] (WW) Falling back to old probe method for modesetting [20.241] (II) modesetting(0): using default device [20.241] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [20.244] (II) modesetting(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [20.244] (==) modesetting(0): Depth 24, (==) framebuffer bpp 32 [20.244] (==) modesetting(0): RGB weight 888 [20.244] (==) modesetting(0): Default visual is TrueColor [20.244] (II) modesetting(0): ShadowFB: preferred NO, enabled NO [20.282] (II) modesetting(0): Output HDMI-0 has no monitor section [20.329] (II) modesetting(0): EDID for output HDMI-0 [20.330] (II) modesetting(0): Manufacturer: RAW Model: 0 Serial#: 1 [20.330] (II) modesetting(0): Year: 2012 Week: 6 [20.330] (II) modesetting(0): EDID Version: 1.3 [20.331] (II) modesetting(0): Digital Display Input [20.331] (II) modesetting(0): Indeterminate output size [20.331] (II) modesetting(0): Gamma: 2.20 [20.331] (II) modesetting(0): No DPMS capabilities specified [20.331] (II) modesetting(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 [20.332] (II) modesetting(0): First detailed timing is preferred mode [20.332] (II) modesetting(0): r
Re: [PATCH v5 00/11] imx-drm dt bindings
On Mon, Apr 07, 2014 at 12:23:37PM +0800, Shawn Guo wrote: > And I see another HDMI regression with my testing on mainline kernel. I > can have my HDMI work at 1920x1080 with v3.14 kernel, but it can only > probes 1024x768 with the mainline today. Works for me here. > [20.606] (II) LoadModule: "modesetting" > [20.607] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so > [20.609] (II) Module modesetting: vendor="X.Org Foundation" > [20.609] compiled for 1.12.1.902, module version = 0.3.0 > [20.610] Module class: X.Org Video Driver > [20.610] ABI class: X.Org Video Driver, version 12.0 > [20.610] (II) modesetting: Driver for Modesetting Kernel Drivers: kms > [20.610] (++) using VT number 7 > > [20.624] (WW) Falling back to old probe method for modesetting > [20.624] (II) modesetting(0): using default device > [20.627] (II) modesetting(0): Creating default Display subsection in > Screen section > "Default Screen Section" for depth/fbbpp 24/32 > [20.627] (==) modesetting(0): Depth 24, (==) framebuffer bpp 32 > [20.628] (==) modesetting(0): RGB weight 888 > [20.628] (==) modesetting(0): Default visual is TrueColor > [20.628] (II) modesetting(0): ShadowFB: preferred NO, enabled NO > [20.628] (II) modesetting(0): Output HDMI-0 has no monitor section > [20.629] (II) modesetting(0): EDID for output HDMI-0 > [20.629] (II) modesetting(0): Printing probed modes for output HDMI-0 So no EDID. Did you update the "ddc" property to "ddc-i2c-bus" ? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
Hi Shawn,
Am Montag, den 07.04.2014, 12:23 +0800 schrieb Shawn Guo:
> On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote:
> > I just came across a couple problems when testing the series on
> > my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it
> > using Russell's branch below, which I believe has all the pieces put
> > together.
> >
> > git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging
> >
> > - When I enable HDMI and LVDS support in both kernel build and device
> > tree, HDMI seems working fine but LVDS color is corrupted quite badly.
>
> Philipp,
>
> Did you get any chance to reproduce this dual display issue? Now it
> shows on mainline kernel.
I have not yet reproduced, but I've sent a patch today ("imx-drm:
imx-drm-core: Fix imx_drm_encoder_get_mux_id") that might fix this.
> And I see another HDMI regression with my testing on mainline kernel. I
> can have my HDMI work at 1920x1080 with v3.14 kernel, but it can only
> probes 1024x768 with the mainline today. The Xorg.0.log are attached
> below. The hardware and user space are same, so I guess this is another
> issue introduced by the recently kernel driver changes?
Hmm, not sure. Have you updated to the i2c-ddc-bus phandle property as
described in Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt?
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
Am Montag, den 07.04.2014, 12:05 +0200 schrieb Philipp Zabel:
> Hi Shawn,
>
> Am Montag, den 07.04.2014, 12:23 +0800 schrieb Shawn Guo:
> > On Tue, Mar 11, 2014 at 11:46:11AM +0800, Shawn Guo wrote:
> > > I just came across a couple problems when testing the series on
> > > my imx6dl-sabresd board in dual display case - HDMI + LVDS. I tested it
> > > using Russell's branch below, which I believe has all the pieces put
> > > together.
> > >
> > > git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging
> > >
> > > - When I enable HDMI and LVDS support in both kernel build and device
> > > tree, HDMI seems working fine but LVDS color is corrupted quite badly.
> >
> > Philipp,
> >
> > Did you get any chance to reproduce this dual display issue? Now it
> > shows on mainline kernel.
>
> I have not yet reproduced, but I've sent a patch today ("imx-drm:
> imx-drm-core: Fix imx_drm_encoder_get_mux_id") that might fix this.
Tested on imx6q-phytec-pbab01 with LVDS panel and DVI monitor.
> > And I see another HDMI regression with my testing on mainline kernel. I
> > can have my HDMI work at 1920x1080 with v3.14 kernel, but it can only
> > probes 1024x768 with the mainline today. The Xorg.0.log are attached
> > below. The hardware and user space are same, so I guess this is another
> > issue introduced by the recently kernel driver changes?
>
> Hmm, not sure. Have you updated to the i2c-ddc-bus phandle property as
> described in Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt?
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
On Mon, Apr 07, 2014 at 10:09:27AM +0100, Russell King - ARM Linux wrote: > So no EDID. Did you update the "ddc" property to "ddc-i2c-bus" ? Ah, right. This is exactly the cause. Thanks, Russell. Shawn ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/11] imx-drm dt bindings
On Mon, Apr 07, 2014 at 12:05:35PM +0200, Philipp Zabel wrote:
> > Did you get any chance to reproduce this dual display issue? Now it
> > shows on mainline kernel.
>
> I have not yet reproduced, but I've sent a patch today ("imx-drm:
> imx-drm-core: Fix imx_drm_encoder_get_mux_id") that might fix this.
Yes, it fixes my issue.
>
> > And I see another HDMI regression with my testing on mainline kernel. I
> > can have my HDMI work at 1920x1080 with v3.14 kernel, but it can only
> > probes 1024x768 with the mainline today. The Xorg.0.log are attached
> > below. The hardware and user space are same, so I guess this is another
> > issue introduced by the recently kernel driver changes?
>
> Hmm, not sure. Have you updated to the i2c-ddc-bus phandle property as
> described in Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt?
That's indeed the cause of my problem. Thanks, Philipp.
Shawn
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
