lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 25 Dec 2015 10:38:17 +0100 From: Jean-Francois Moine <moinejf@...e.fr> To: Russell King - ARM Linux <linux@....linux.org.uk> Cc: Liviu Dudau <Liviu.Dudau@....com>, linux-rockchip <linux-rockchip@...ts.infradead.org>, Daniel Vetter <daniel.vetter@...ll.ch>, LKML <linux-kernel@...r.kernel.org>, dri-devel <dri-devel@...ts.freedesktop.org>, LAKML <linux-arm-kernel@...ts.infradead.org>, devicetree@...r.kernel.org Subject: Re: [PATCH v2 0/2] Improve drm_of_component_probe() and move rockchip to use it On Thu, 24 Dec 2015 12:36:10 +0000 Russell King - ARM Linux <linux@....linux.org.uk> wrote: > It seems that you're trying to work around a limitation in Linux by > modifying the hardware representation... Sorry to come back to this topic, but I think you are wrong. Looking at the imx6 DTs, the problem comes from the display-subsystem node which is a pure Linux specific software entity. If you want to describe only the hardware in the DT, everything is simple. A IPU is a image controller with its sub-devices. Seen from the system, it is like a 'board' with its devices (LCDs, camera...). When 2 IPUs, there are 2 independant boards. Here is what could be a pure hardware DT: /* no display-subsystem */ ipu1: ipu@...00000 { /* image controller / board 1 */ compatible = "fsl,imx6q-ipu"; ... ports = <&ipu1_di0>, <&ipu1_di1>; }; ipu1_di0: di@0 { /* display interface / crtc 1 */ compatible = "fsl,imx6q-di"; ... ipu1_di0_hdmi: endpoint@1 { remote-endpoint = <&hdmi_mux_0>; }; ipu1_di0_mipi: endpoint@2 { remote-endpoint = <&mipi_mux_0>; } ... }; ipu1_di1: di@1 { /* display interface / crtc 2 */ compatible = "fsl,imx6q-di"; ... ipu1_di1_hdmi: endpoint@1 { remote-endpoint = <&hdmi_mux_1>; }; ipu1_di1_mipi: endpoint@2 { remote-endpoint = <&mipi_mux_1>; } ... }; ipu2: ipu@...00000 { /* image controller / board 2 */ compatible = "fsl,imx6q-ipu"; ... ports = <&ipu2_di0>, <&ipu2_di1>; }; ipu2_di0: di@0 { /* display interface / crtc 1 */ compatible = "fsl,imx6q-di"; ... ipu2_di0_hdmi: endpoint@1 { remote-endpoint = <&hdmi_mux_2>; }; ipu2_di0_mipi: endpoint@2 { remote-endpoint = <&mipi_mux_2>; } ... }; ipu2_di1: di@1 { /* display interface / crtc 2 */ compatible = "fsl,imx6q-di"; ... ipu2_di1_hdmi: endpoint@1 { remote-endpoint = <&hdmi_mux_3>; }; ipu2_di1_mipi: endpoint@2 { remote-endpoint = <&mipi_mux_3>; } ... }; Then, a standard component binding (port->parent) works fine... (you may note that the same problem exists with audio: the 'simple-card' is also a pure Linux specific software entity) -- Merry Christmas | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists