From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar Gala Subject: Re: [PATCHv3][ 3/5] video: mx3fb: Add device tree suport. Date: Sat, 26 Oct 2013 01:43:23 -0500 Message-ID: <93D2899F-E285-4794-8F32-AD55360A4A80@codeaurora.org> References: <1382532229-32755-1-git-send-email-denis@eukrea.com> <1382532229-32755-3-git-send-email-denis@eukrea.com> <20131025195040.0CCC3C404DA@trevor.secretlab.ca> <20131026001854.GE17135@pengutronix.de> Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20131026001854.GE17135-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sascha Hauer Cc: Grant Likely , Denis Carikli , Sascha Hauer , Mark Rutland , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Pawel Moll , Stephen Warren , Ian Campbell , Rob Herring , Tomi Valkeinen , =?iso-8859-1?Q?Eric_B=E9nard?= , Shawn Guo , Jean-Christophe Plagniol-Villard , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On Oct 25, 2013, at 7:18 PM, Sascha Hauer wrote: > On Fri, Oct 25, 2013 at 08:50:40PM +0100, Grant Likely wrote: >> On Wed, 23 Oct 2013 14:43:47 +0200, Denis Carikli = wrote: >>> Cc: Jean-Christophe Plagniol-Villard >>> Cc: Tomi Valkeinen >>> Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >>> Cc: Rob Herring >>> Cc: Pawel Moll >>> Cc: Mark Rutland >>> Cc: Stephen Warren >>> Cc: Ian Campbell >>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >>> Cc: Sascha Hauer >>> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org >>> Cc: Eric B=E9nard >>> Signed-off-by: Denis Carikli >>> --- >>> ChangeLog v2->v3: >>> - The device tree bindings were reworked in order to make it look m= ore like the >>> IPUv3 bindings. >>> - The interface_pix_fmt property now looks like the IPUv3 one. >>> --- >>> .../devicetree/bindings/video/fsl,mx3-fb.txt | 35 ++++++ >>> drivers/video/Kconfig | 2 + >>> drivers/video/mx3fb.c | 125 +++++++++= ++++++++--- >>> 3 files changed, 147 insertions(+), 15 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/video/fsl,mx3-= fb.txt >>>=20 >>> 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..0b31374 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/video/fsl,mx3-fb.txt >>> @@ -0,0 +1,35 @@ >>> +Freescale MX3 fb >>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> + >>> +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 dat= asheet. >>> +- clocks: Handle to the ipu_gate clock. >>> + >>> +Example: >>> + >>> +lcdc: mx3fb@53fc00b4 { >>> + compatible =3D "fsl,mx3-fb"; >>> + reg =3D <0x53fc00b4 0x0b>; >>> + clocks =3D <&clks 55>; >>> +}; >>=20 >> This (and some of the other bindings) are trivial, and they are all >> associated with a single SoC. I think it would be better to collect = all >> the mx3 bindings into a single file rather than distributing them al= l >> over the bindings tree. >>=20 >> I started thinking about this after some of the DT conversations in >> Edinburgh this week. Unless there is a high likelyhood of components >> being used separately, I think it is far more useful to collect all = the >> bindings for an SoC into a single file. It will certainly reduce a l= ot >> of the boilerplate that we've been collecting in bindings documentat= ion >> files. >>=20 >> A long time ago I took that approach for the mpc5200 documentation[1= ]. >> Take a look at that organization and let me know what you think. >=20 > I don't think this is a good idea. When a new SoC comes out we don't > know which components will be reused on the next SoC. This will cause= a > lot of bikeshedding when it actually is reused and then has to be mov= ed. >=20 > Also I would find it quite inconsistent if I had to lookup some devic= es > in a SoC file and most bindings in subsystem specific files. So when > searching for a binding I would first have to know if the hardware is > unique to the SoC or not. I agree that as new SoC come out its better to have these things split = out. Also for IP that is sold by vendors like Synopsys/Designware that= get used on a lot of SoCs its makes it easier to ensure consistency by= having the binding split out for the IP and not the SoC. Also, by having bindings for similar devices for different SoCs kept to= gether it becomes easier for us to see patterns across SoCs as we might= come up with a more generic binding in the future. Far more difficult= if things are SoC oriented. - k --=20 Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, host= ed by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar Gala Date: Sat, 26 Oct 2013 06:43:23 +0000 Subject: Re: [PATCHv3][ 3/5] video: mx3fb: Add device tree suport. Message-Id: <93D2899F-E285-4794-8F32-AD55360A4A80@codeaurora.org> List-Id: References: <1382532229-32755-1-git-send-email-denis@eukrea.com> <1382532229-32755-3-git-send-email-denis@eukrea.com> <20131025195040.0CCC3C404DA@trevor.secretlab.ca> <20131026001854.GE17135@pengutronix.de> In-Reply-To: <20131026001854.GE17135@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-arm-kernel@lists.infradead.org On Oct 25, 2013, at 7:18 PM, Sascha Hauer wrote: > On Fri, Oct 25, 2013 at 08:50:40PM +0100, Grant Likely wrote: >> On Wed, 23 Oct 2013 14:43:47 +0200, Denis Carikli wro= te: >>> Cc: Jean-Christophe Plagniol-Villard >>> Cc: Tomi Valkeinen >>> Cc: linux-fbdev@vger.kernel.org >>> Cc: Rob Herring >>> Cc: Pawel Moll >>> Cc: Mark Rutland >>> Cc: Stephen Warren >>> Cc: Ian Campbell >>> Cc: devicetree@vger.kernel.org >>> Cc: Sascha Hauer >>> Cc: linux-arm-kernel@lists.infradead.org >>> Cc: Eric B=E9nard >>> Signed-off-by: Denis Carikli >>> --- >>> 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 | 35 ++++++ >>> drivers/video/Kconfig | 2 + >>> drivers/video/mx3fb.c | 125 +++++++++++++= ++++--- >>> 3 files changed, 147 insertions(+), 15 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/video/fsl,mx3-fb.t= xt >>>=20 >>> diff --git a/Documentation/devicetree/bindings/video/fsl,mx3-fb.txt b/D= ocumentation/devicetree/bindings/video/fsl,mx3-fb.txt >>> new file mode 100644 >>> index 0000000..0b31374 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/video/fsl,mx3-fb.txt >>> @@ -0,0 +1,35 @@ >>> +Freescale MX3 fb >>> +=3D=3D=3D=3D=3D=3D=3D=3D >>> + >>> +Required properties: >>> +- compatible: Should be "fsl,mx3fb". compatible chips include the imx3= 1 and the >>> + imx35. >>> +- reg: should be register base and length as documented in the datashe= et. >>> +- clocks: Handle to the ipu_gate clock. >>> + >>> +Example: >>> + >>> +lcdc: mx3fb@53fc00b4 { >>> + compatible =3D "fsl,mx3-fb"; >>> + reg =3D <0x53fc00b4 0x0b>; >>> + clocks =3D <&clks 55>; >>> +}; >>=20 >> This (and some of the other bindings) are trivial, and they are all >> associated with a single SoC. I think it would be better to collect all >> the mx3 bindings into a single file rather than distributing them all >> over the bindings tree. >>=20 >> I started thinking about this after some of the DT conversations in >> Edinburgh this week. Unless there is a high likelyhood of components >> being used separately, I think it is far more useful to collect all the >> bindings for an SoC into a single file. It will certainly reduce a lot >> of the boilerplate that we've been collecting in bindings documentation >> files. >>=20 >> A long time ago I took that approach for the mpc5200 documentation[1]. >> Take a look at that organization and let me know what you think. >=20 > I don't think this is a good idea. When a new SoC comes out we don't > know which components will be reused on the next SoC. This will cause a > lot of bikeshedding when it actually is reused and then has to be moved. >=20 > Also I would find it quite inconsistent if I had to lookup some devices > in a SoC file and most bindings in subsystem specific files. So when > searching for a binding I would first have to know if the hardware is > unique to the SoC or not. I agree that as new SoC come out its better to have these things split out.= Also for IP that is sold by vendors like Synopsys/Designware that get use= d on a lot of SoCs its makes it easier to ensure consistency by having the = binding split out for the IP and not the SoC. Also, by having bindings for similar devices for different SoCs kept togeth= er it becomes easier for us to see patterns across SoCs as we might come up= with a more generic binding in the future. Far more difficult if things a= re SoC oriented. - k --=20 Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted b= y The Linux Foundation From mboxrd@z Thu Jan 1 00:00:00 1970 From: galak@codeaurora.org (Kumar Gala) Date: Sat, 26 Oct 2013 01:43:23 -0500 Subject: [PATCHv3][ 3/5] video: mx3fb: Add device tree suport. In-Reply-To: <20131026001854.GE17135@pengutronix.de> References: <1382532229-32755-1-git-send-email-denis@eukrea.com> <1382532229-32755-3-git-send-email-denis@eukrea.com> <20131025195040.0CCC3C404DA@trevor.secretlab.ca> <20131026001854.GE17135@pengutronix.de> Message-ID: <93D2899F-E285-4794-8F32-AD55360A4A80@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Oct 25, 2013, at 7:18 PM, Sascha Hauer wrote: > On Fri, Oct 25, 2013 at 08:50:40PM +0100, Grant Likely wrote: >> On Wed, 23 Oct 2013 14:43:47 +0200, Denis Carikli wrote: >>> Cc: Jean-Christophe Plagniol-Villard >>> Cc: Tomi Valkeinen >>> Cc: linux-fbdev at vger.kernel.org >>> Cc: Rob Herring >>> Cc: Pawel Moll >>> Cc: Mark Rutland >>> Cc: Stephen Warren >>> Cc: Ian Campbell >>> Cc: devicetree at vger.kernel.org >>> Cc: Sascha Hauer >>> Cc: linux-arm-kernel at lists.infradead.org >>> Cc: Eric B?nard >>> Signed-off-by: Denis Carikli >>> --- >>> 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 | 35 ++++++ >>> drivers/video/Kconfig | 2 + >>> drivers/video/mx3fb.c | 125 +++++++++++++++++--- >>> 3 files changed, 147 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..0b31374 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/video/fsl,mx3-fb.txt >>> @@ -0,0 +1,35 @@ >>> +Freescale MX3 fb >>> +================ >>> + >>> +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. >>> + >>> +Example: >>> + >>> +lcdc: mx3fb at 53fc00b4 { >>> + compatible = "fsl,mx3-fb"; >>> + reg = <0x53fc00b4 0x0b>; >>> + clocks = <&clks 55>; >>> +}; >> >> This (and some of the other bindings) are trivial, and they are all >> associated with a single SoC. I think it would be better to collect all >> the mx3 bindings into a single file rather than distributing them all >> over the bindings tree. >> >> I started thinking about this after some of the DT conversations in >> Edinburgh this week. Unless there is a high likelyhood of components >> being used separately, I think it is far more useful to collect all the >> bindings for an SoC into a single file. It will certainly reduce a lot >> of the boilerplate that we've been collecting in bindings documentation >> files. >> >> A long time ago I took that approach for the mpc5200 documentation[1]. >> Take a look at that organization and let me know what you think. > > I don't think this is a good idea. When a new SoC comes out we don't > know which components will be reused on the next SoC. This will cause a > lot of bikeshedding when it actually is reused and then has to be moved. > > Also I would find it quite inconsistent if I had to lookup some devices > in a SoC file and most bindings in subsystem specific files. So when > searching for a binding I would first have to know if the hardware is > unique to the SoC or not. I agree that as new SoC come out its better to have these things split out. Also for IP that is sold by vendors like Synopsys/Designware that get used on a lot of SoCs its makes it easier to ensure consistency by having the binding split out for the IP and not the SoC. Also, by having bindings for similar devices for different SoCs kept together it becomes easier for us to see patterns across SoCs as we might come up with a more generic binding in the future. Far more difficult if things are SoC oriented. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation