| Message ID | 1521662593-25468-7-git-send-email-giulio.benetti@micronovasrl.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote: > The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production > label, is an industrial Human Machine Interface. > It features: > - 512MB DDR RAM > - 1 Sd-card >= 4GB > - 1 Usb otg(programmable via software) with A-Usb Connector > - 1 Usb host > - 1 Buzzer > - 1 Input for LiPo > - 1 Relay to signal absence of power supply > - 1 External Rtc with 56 bytes of ram + CR2032 battery > - 1 7" 24-bits Tft 800x480 with PCap on > - 1 Mono audio 1-watt amplifier > - 1 RS485 port > - 1 Power On Line through +12Vdc reaching 57.600baud, > from where it can be supplied and placed in a network of 50 units > - exposed jtag pins > > HMI is supplied from +12Vdc. > Ethernet is absent, so for debugging, need to enable rndis on Usb otg > port through an A-A usb cable. > It comes in different flavours for connector types and can be found with > umounted features as requested by customers. So this is essentially the same board than in patch 6, but with a different screen? You should have a single DT then, and handle the two different panels using DT overlays. > Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> > --- > .../devicetree/bindings/arm/micronova.txt | 4 + > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 +++++++++++++++++++++ > 3 files changed, 197 insertions(+) > create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts > > diff --git a/Documentation/devicetree/bindings/arm/micronova.txt b/Documentation/devicetree/bindings/arm/micronova.txt > index 35c4127..9f5ac72 100644 > --- a/Documentation/devicetree/bindings/arm/micronova.txt > +++ b/Documentation/devicetree/bindings/arm/micronova.txt > @@ -4,3 +4,7 @@ Micronova Device Tree Bindings > A20-LiNova1-4_3 HMI > Required root node properties: > - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20"; > + > +A20-LiNova1-7 HMI > +Required root node properties: > + - compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20"; These bindings are unnecessary, but the panel-simple bindings should be sent to the DT maintainers as well. > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index c45a4f25..eafa7cb 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \ > sun7i-a20-m3.dtb \ > sun7i-a20-mk808c.dtb \ > sun7i-a20-linova1-ctp-4_3i.dtb\ > + sun7i-a20-linova1-ctp-7i.dtb\ You should have a space after dtb, and it should be ordered alphabetically. > sun7i-a20-olimex-som-evb.dtb \ > sun7i-a20-olinuxino-lime.dtb \ > sun7i-a20-olinuxino-lime2.dtb \ > diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts > new file mode 100644 > index 0000000..7fd0d98 > --- /dev/null > +++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts > @@ -0,0 +1,192 @@ > +/* > + * This is based on sun7i-a20-linova1-ctp-7i.dts > + * > + * Copyright 2014 - Hans de Goede <hdegoede@redhat.com> > + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com> > + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com> > + * > + * This file is dual-licensed: you can use it either under the terms > + * of the GPL or the X11 license, at your option. Note that this dual > + * licensing only applies to this file, and not this project as a > + * whole. > + * > + * a) This file 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 file 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. > + * > + * Or, alternatively, > + * > + * b) Permission is hereby granted, free of charge, to any person > + * obtaining a copy of this software and associated documentation > + * files (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, > + * copy, modify, merge, publish, distribute, sublicense, and/or > + * sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following > + * conditions: > + * > + * The above copyright notice and this permission notice shall be > + * included in all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ You should use an SPDX license header here. > + > +/dts-v1/; > +#include "sun7i-a20.dtsi" > +#include "sunxi-common-regulators.dtsi" > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/interrupt-controller/irq.h> > + > +/ { > + model = "Micronova srl LiNova1 CTP 7i"; > + compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20"; > + > + aliases { > + serial0 = &uart0; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > + > + panel: panel { > + compatible = "cdtech,s070wv95-ct16", "simple-panel"; > + power-supply = <®_vcc3v3>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + panel_input: endpoint@0 { > + reg = <0>; > + remote-endpoint = <&tcon0_out_panel>; > + }; > + }; > + }; > +}; > + > +&ehci0 { > + status = "okay"; > +}; > + > +&ehci1 { > + status = "okay"; > +}; > + > +&i2c0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&i2c0_pins_a>; > + status = "okay"; > + > + axp209: pmic@34 { > + compatible = "x-powers,axp209"; > + reg = <0x34>; > + interrupt-parent = <&nmi_intc>; > + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; > + > + interrupt-controller; > + #interrupt-cells = <1>; > + }; > +}; > + > +&i2c2 { > + pinctrl-names = "default"; > + pinctrl-0 = <&i2c2_pins_a>; > + status = "okay"; > + > + ft5x: touchscreen@38 { > + compatible = "edt,edt-ft5206"; > + reg = <0x38>; > + interrupt-parent = <&pio>; > + interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */ > + reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */ > + touchscreen-size-x = <800>; > + touchscreen-size-y = <480>; > + }; > +}; > + > +&mmc0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&mmc0_pins_a>; > + vmmc-supply = <®_vcc3v3>; > + bus-width = <4>; > + cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */ > + cd-inverted; > + status = "okay"; > +}; > + > +&ohci0 { > + status = "okay"; > +}; > + > +&ohci1 { > + status = "okay"; > +}; > + > +&otg_sram { > + status = "okay"; > +}; > + > +®_usb0_vbus { > + status = "okay"; > +}; > + > +®_usb1_vbus { > + status = "okay"; > +}; Ideally you should be defining the regulators here too. > +&uart0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&uart0_pins_a>; > + status = "okay"; > +}; > + > +&usb_otg { > + dr_mode = "otg"; You're saying that this is a USB-A connector? Then it's not OTG since it doesn't have an ID pin, this is an host. > + status = "okay"; > +}; > + > +&usbphy { > + pinctrl-names = "default"; > + usb0_vbus-supply = <®_usb0_vbus>; > + usb1_vbus-supply = <®_usb1_vbus>; > + status = "okay"; > +}; > + > +&be0 { > + status = "okay"; > +}; > + > +&de { > + status = "okay"; > +}; The nodes should be ordered by alphabetical order. Thanks! Maxime
Hi, Il 22/03/2018 19:05, Maxime Ripard ha scritto: > On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote: >> The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production >> label, is an industrial Human Machine Interface. >> It features: >> - 512MB DDR RAM >> - 1 Sd-card >= 4GB >> - 1 Usb otg(programmable via software) with A-Usb Connector >> - 1 Usb host >> - 1 Buzzer >> - 1 Input for LiPo >> - 1 Relay to signal absence of power supply >> - 1 External Rtc with 56 bytes of ram + CR2032 battery >> - 1 7" 24-bits Tft 800x480 with PCap on >> - 1 Mono audio 1-watt amplifier >> - 1 RS485 port >> - 1 Power On Line through +12Vdc reaching 57.600baud, >> from where it can be supplied and placed in a network of 50 units >> - exposed jtag pins >> >> HMI is supplied from +12Vdc. >> Ethernet is absent, so for debugging, need to enable rndis on Usb otg >> port through an A-A usb cable. >> It comes in different flavours for connector types and can be found with >> umounted features as requested by customers. > > So this is essentially the same board than in patch 6, but with a > different screen? > > You should have a single DT then, and handle the two different panels > using DT overlays. Ok for having different DT overlays. But do I have to submit them as patches? Or keep them in my company's repo? I ask you this because this involves sending also patches for displays and other little modifications to mainline ex: - rgb888 pins - 2 simple-panels - 1 uart iomux pins etc. If I don't submit those overlays, the other patches wouldn't make sense alone as I've seen, just like rgb888 pins. > >> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> >> --- >> .../devicetree/bindings/arm/micronova.txt | 4 + >> arch/arm/boot/dts/Makefile | 1 + >> arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 +++++++++++++++++++++ >> 3 files changed, 197 insertions(+) >> create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts >> >> diff --git a/Documentation/devicetree/bindings/arm/micronova.txt b/Documentation/devicetree/bindings/arm/micronova.txt >> index 35c4127..9f5ac72 100644 >> --- a/Documentation/devicetree/bindings/arm/micronova.txt >> +++ b/Documentation/devicetree/bindings/arm/micronova.txt >> @@ -4,3 +4,7 @@ Micronova Device Tree Bindings >> A20-LiNova1-4_3 HMI >> Required root node properties: >> - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20"; >> + >> +A20-LiNova1-7 HMI >> +Required root node properties: >> + - compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20"; > > These bindings are unnecessary, but the panel-simple bindings should > be sent to the DT maintainers as well. Ok, removed them and already sent the ones for display. > >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >> index c45a4f25..eafa7cb 100644 >> --- a/arch/arm/boot/dts/Makefile >> +++ b/arch/arm/boot/dts/Makefile >> @@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \ >> sun7i-a20-m3.dtb \ >> sun7i-a20-mk808c.dtb \ >> sun7i-a20-linova1-ctp-4_3i.dtb\ >> + sun7i-a20-linova1-ctp-7i.dtb\ > > You should have a space after dtb, and it should be ordered > alphabetically. Done. > >> sun7i-a20-olimex-som-evb.dtb \ >> sun7i-a20-olinuxino-lime.dtb \ >> sun7i-a20-olinuxino-lime2.dtb \ >> diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts >> new file mode 100644 >> index 0000000..7fd0d98 >> --- /dev/null >> +++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts >> @@ -0,0 +1,192 @@ >> +/* >> + * This is based on sun7i-a20-linova1-ctp-7i.dts >> + * >> + * Copyright 2014 - Hans de Goede <hdegoede@redhat.com> >> + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com> >> + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com> >> + * >> + * This file is dual-licensed: you can use it either under the terms >> + * of the GPL or the X11 license, at your option. Note that this dual >> + * licensing only applies to this file, and not this project as a >> + * whole. >> + * >> + * a) This file 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 file 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. >> + * >> + * Or, alternatively, >> + * >> + * b) Permission is hereby granted, free of charge, to any person >> + * obtaining a copy of this software and associated documentation >> + * files (the "Software"), to deal in the Software without >> + * restriction, including without limitation the rights to use, >> + * copy, modify, merge, publish, distribute, sublicense, and/or >> + * sell copies of the Software, and to permit persons to whom the >> + * Software is furnished to do so, subject to the following >> + * conditions: >> + * >> + * The above copyright notice and this permission notice shall be >> + * included in all copies or substantial portions of the Software. >> + * >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, >> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES >> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND >> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT >> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, >> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR >> + * OTHER DEALINGS IN THE SOFTWARE. >> + */ > > You should use an SPDX license header here. Done > >> + >> +/dts-v1/; >> +#include "sun7i-a20.dtsi" >> +#include "sunxi-common-regulators.dtsi" >> + >> +#include <dt-bindings/gpio/gpio.h> >> +#include <dt-bindings/interrupt-controller/irq.h> >> + >> +/ { >> + model = "Micronova srl LiNova1 CTP 7i"; >> + compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20"; >> + >> + aliases { >> + serial0 = &uart0; >> + }; >> + >> + chosen { >> + stdout-path = "serial0:115200n8"; >> + }; >> + >> + panel: panel { >> + compatible = "cdtech,s070wv95-ct16", "simple-panel"; >> + power-supply = <®_vcc3v3>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + port@0 { >> + reg = <0>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + panel_input: endpoint@0 { >> + reg = <0>; >> + remote-endpoint = <&tcon0_out_panel>; >> + }; >> + }; >> + }; >> +}; >> + >> +&ehci0 { >> + status = "okay"; >> +}; >> + >> +&ehci1 { >> + status = "okay"; >> +}; >> + >> +&i2c0 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&i2c0_pins_a>; >> + status = "okay"; >> + >> + axp209: pmic@34 { >> + compatible = "x-powers,axp209"; >> + reg = <0x34>; >> + interrupt-parent = <&nmi_intc>; >> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; >> + >> + interrupt-controller; >> + #interrupt-cells = <1>; >> + }; >> +}; >> + >> +&i2c2 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&i2c2_pins_a>; >> + status = "okay"; >> + >> + ft5x: touchscreen@38 { >> + compatible = "edt,edt-ft5206"; >> + reg = <0x38>; >> + interrupt-parent = <&pio>; >> + interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */ >> + reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */ >> + touchscreen-size-x = <800>; >> + touchscreen-size-y = <480>; >> + }; >> +}; >> + >> +&mmc0 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&mmc0_pins_a>; >> + vmmc-supply = <®_vcc3v3>; >> + bus-width = <4>; >> + cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */ >> + cd-inverted; >> + status = "okay"; >> +}; >> + >> +&ohci0 { >> + status = "okay"; >> +}; >> + >> +&ohci1 { >> + status = "okay"; >> +}; >> + >> +&otg_sram { >> + status = "okay"; >> +}; >> + >> +®_usb0_vbus { >> + status = "okay"; >> +}; >> + >> +®_usb1_vbus { >> + status = "okay"; >> +}; > > Ideally you should be defining the regulators here too. Added. > >> +&uart0 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&uart0_pins_a>; >> + status = "okay"; >> +}; >> + >> +&usb_otg { >> + dr_mode = "otg"; > > You're saying that this is a USB-A connector? Then it's not OTG since > it doesn't have an ID pin, this is an host. Right, with a special overlay I will activate Usb Device for RNDIS, so modified as host > >> + status = "okay"; >> +}; >> + >> +&usbphy { >> + pinctrl-names = "default"; >> + usb0_vbus-supply = <®_usb0_vbus>; >> + usb1_vbus-supply = <®_usb1_vbus>; >> + status = "okay"; >> +}; >> + >> +&be0 { >> + status = "okay"; >> +}; >> + >> +&de { >> + status = "okay"; >> +}; > > The nodes should be ordered by alphabetical order. Done. One last question: now I have some patch already reviewed-by. Do I have to re-submit entire patchset? Thank you very much.
Hi, On Mon, Apr 23, 2018 at 04:37:33PM +0200, Giulio Benetti wrote: > Il 22/03/2018 19:05, Maxime Ripard ha scritto: > > On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote: > > > The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production > > > label, is an industrial Human Machine Interface. > > > It features: > > > - 512MB DDR RAM > > > - 1 Sd-card >= 4GB > > > - 1 Usb otg(programmable via software) with A-Usb Connector > > > - 1 Usb host > > > - 1 Buzzer > > > - 1 Input for LiPo > > > - 1 Relay to signal absence of power supply > > > - 1 External Rtc with 56 bytes of ram + CR2032 battery > > > - 1 7" 24-bits Tft 800x480 with PCap on > > > - 1 Mono audio 1-watt amplifier > > > - 1 RS485 port > > > - 1 Power On Line through +12Vdc reaching 57.600baud, > > > from where it can be supplied and placed in a network of 50 units > > > - exposed jtag pins > > > > > > HMI is supplied from +12Vdc. > > > Ethernet is absent, so for debugging, need to enable rndis on Usb otg > > > port through an A-A usb cable. > > > It comes in different flavours for connector types and can be found with > > > umounted features as requested by customers. > > > > So this is essentially the same board than in patch 6, but with a > > different screen? > > > > You should have a single DT then, and handle the two different panels > > using DT overlays. > > Ok for having different DT overlays. > But do I have to submit them as patches? Or keep them in my company's repo? > I ask you this because this involves sending also patches for displays > and other little modifications to mainline ex: > - rgb888 pins > - 2 simple-panels > - 1 uart iomux pins > etc. > > If I don't submit those overlays, the other patches wouldn't make sense > alone as I've seen, just like rgb888 pins. We don't have a repo for overlays yet > > > +&usb_otg { > > > + dr_mode = "otg"; > > > > You're saying that this is a USB-A connector? Then it's not OTG since > > it doesn't have an ID pin, this is an host. > > Right, with a special overlay I will activate Usb Device for RNDIS, > so modified as host That doesn't really make much sense. The USB OTG is wired only using a daughter board? > One last question: > now I have some patch already reviewed-by. > Do I have to re-submit entire patchset? Yes Maxime
Hi Maxime and all, I resend the e-mail since it was refused by some address(my phone composed it in HTML). Sorry. Il 24/04/2018 10:41, Maxime Ripard ha scritto: > Hi, > > On Mon, Apr 23, 2018 at 04:37:33PM +0200, Giulio Benetti wrote: >> Il 22/03/2018 19:05, Maxime Ripard ha scritto: >>> On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote: >>>> The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production >>>> label, is an industrial Human Machine Interface. >>>> It features: >>>> - 512MB DDR RAM >>>> - 1 Sd-card >= 4GB >>>> - 1 Usb otg(programmable via software) with A-Usb Connector >>>> - 1 Usb host >>>> - 1 Buzzer >>>> - 1 Input for LiPo >>>> - 1 Relay to signal absence of power supply >>>> - 1 External Rtc with 56 bytes of ram + CR2032 battery >>>> - 1 7" 24-bits Tft 800x480 with PCap on >>>> - 1 Mono audio 1-watt amplifier >>>> - 1 RS485 port >>>> - 1 Power On Line through +12Vdc reaching 57.600baud, >>>> from where it can be supplied and placed in a network of 50 units >>>> - exposed jtag pins >>>> >>>> HMI is supplied from +12Vdc. >>>> Ethernet is absent, so for debugging, need to enable rndis on Usb otg >>>> port through an A-A usb cable. >>>> It comes in different flavours for connector types and can be found with >>>> umounted features as requested by customers. >>> >>> So this is essentially the same board than in patch 6, but with a >>> different screen? >>> >>> You should have a single DT then, and handle the two different panels >>> using DT overlays. >> >> Ok for having different DT overlays. >> But do I have to submit them as patches? Or keep them in my company's repo? >> I ask you this because this involves sending also patches for displays >> and other little modifications to mainline ex: >> - rgb888 pins >> - 2 simple-panels >> - 1 uart iomux pins >> etc. >> >> If I don't submit those overlays, the other patches wouldn't make sense >> alone as I've seen, just like rgb888 pins. > > We don't have a repo for overlays yet Ok I can provide them on my company Repo. But, sorry if insist(please don't kill me! :) ), I would try to explain better how it's made LiNova, because I think I didn't provide enough information about it: LiNova1 is not a board with various headers to connect other peripherals such display, pcap etc. It's an HMI that I would consider the same as a Tablet, because it has a plastic enclosure also. So I would like to understand how to manage it in the best way. Try to consider LiNova1 as a Tablet series, with following list: LiNova1 4.3" ctp LiNova1 7" ctp LiNova1 10.1" ctp LiNova1 4.3" rtp LiNova1 7" rtp LiNova1 10.1" rtp Every of those has a slightly different BOM, so they are 6 different boards with a common base(uP, ram). And same pcb. So I don't know if submit only the common base and provide separately on our github DT-overlays, or provide as many dts patches as the HMI number with a base dtsi. Basically Micronova provides entire system without the capability to hack hardware adding shields of various type. There are also other 2 LiNova: LiNova2 and LiNova3 So I understand that this could lead to 18 different dts files and 3 dtsi files. But with Tablet it should be the same way. For sure people would be more interested on famous tablets instead of our HMI. In the case I need to use dt-overlays, you mean .dto files with fragments inside loaded by u-boot or runtime, right? Sorry if I bother you again but I wanted to understand better. > >>>> +&usb_otg { >>>> + dr_mode = "otg"; >>> >>> You're saying that this is a USB-A connector? Then it's not OTG since >>> it doesn't have an ID pin, this is an host. >> >> Right, with a special overlay I will activate Usb Device for RNDIS, >> so modified as host > > That doesn't really make much sense. The USB OTG is wired only using a > daughter board? My fault, I've meant "peripheral" in one case and "host" in another case. Usually "host". Are there problem with this? There is no daughter board. Thank you very very much in advance for you patience :)
Hi Giulio, On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote: > LiNova1 is not a board with various headers to connect other peripherals > such display, pcap etc. > It's an HMI that I would consider the same as a Tablet, because it has a > plastic enclosure also. > > So I would like to understand how to manage it in the best way. > Try to consider LiNova1 as a Tablet series, with following list: > LiNova1 4.3" ctp > LiNova1 7" ctp > LiNova1 10.1" ctp > LiNova1 4.3" rtp > LiNova1 7" rtp > LiNova1 10.1" rtp > > Every of those has a slightly different BOM, so they are 6 different > boards with a common base(uP, ram). And same pcb. So the LiNova1 is exactly the same in all these setups, the only difference is that it has a connector that you connect a different display / touchscreen to? If so, that's definitely a case for device tree overlays. > So I don't know if submit only the common base and provide > separately on our github DT-overlays, or provide as many dts patches > as the HMI number with a base dtsi. That's really up to you, but the overlays will make this much simpler to handle precisely because it will reduce the amount of combinations you have. You can even reduce it in your case to 5 of them, 3 for each panel and 2 for each touchscreen. > Basically Micronova provides entire system without the capability to hack > hardware adding shields of various type. > > There are also other 2 LiNova: > LiNova2 and LiNova3 Which SoCs are these boards based on? > So I understand that this could lead to 18 different dts files and 3 > dtsi files. Yeah, I'd really like to keep this under control :) > But with Tablet it should be the same way. For sure people would be > more interested on famous tablets instead of our HMI. > > In the case I need to use dt-overlays, you mean .dto files with > fragments inside loaded by u-boot or runtime, right? You don't have to handcode the fragments anymore with the new syntax, and U-Boot makes it really trivial to use if you use the FIT image format to have multiple overlays bundled in the same image. You can choose to apply them dynamically, for example based on an EEPROM or some other metric to see which combination you have. > > > > > +&usb_otg { > > > > > + dr_mode = "otg"; > > > > > > > > You're saying that this is a USB-A connector? Then it's not OTG since > > > > it doesn't have an ID pin, this is an host. > > > > > > Right, with a special overlay I will activate Usb Device for RNDIS, > > > so modified as host > > > > That doesn't really make much sense. The USB OTG is wired only using a > > daughter board? > > My fault, I've meant "peripheral" in one case and "host" in another case. > Usually "host". > Are there problem with this? > There is no daughter board. If you have an ID pin and the ability to control VBUS, then you don't need to change the device tree, it's done automatically at runtime by Linux. Maxime
Hi Maxime, Il 25/04/2018 20:40, Maxime Ripard ha scritto: > Hi Giulio, > > On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote: >> LiNova1 is not a board with various headers to connect other peripherals >> such display, pcap etc. >> It's an HMI that I would consider the same as a Tablet, because it has a >> plastic enclosure also. >> >> So I would like to understand how to manage it in the best way. >> Try to consider LiNova1 as a Tablet series, with following list: >> LiNova1 4.3" ctp >> LiNova1 7" ctp >> LiNova1 10.1" ctp >> LiNova1 4.3" rtp >> LiNova1 7" rtp >> LiNova1 10.1" rtp >> >> Every of those has a slightly different BOM, so they are 6 different >> boards with a common base(uP, ram). And same pcb. > > So the LiNova1 is exactly the same in all these setups, the only > difference is that it has a connector that you connect a different > display / touchscreen to? > > If so, that's definitely a case for device tree overlays. Yes it is that way. So I proceed with dt overlays. > >> So I don't know if submit only the common base and provide >> separately on our github DT-overlays, or provide as many dts patches >> as the HMI number with a base dtsi. > > That's really up to you, but the overlays will make this much simpler > to handle precisely because it will reduce the amount of combinations > you have. > > You can even reduce it in your case to 5 of them, 3 for each panel and > 2 for each touchscreen. Ah, that's right! Good idea, more "encapsulation". > >> Basically Micronova provides entire system without the capability to hack >> hardware adding shields of various type. >> >> There are also other 2 LiNova: >> LiNova2 and LiNova3 > > Which SoCs are these boards based on? A20 on all three. They are slightly between each other. Some RS485 more, 1 USB more etc. > >> So I understand that this could lead to 18 different dts files and 3 >> dtsi files. > > Yeah, I'd really like to keep this under control :) :) > >> But with Tablet it should be the same way. For sure people would be >> more interested on famous tablets instead of our HMI. >> >> In the case I need to use dt-overlays, you mean .dto files with >> fragments inside loaded by u-boot or runtime, right? > > You don't have to handcode the fragments anymore with the new syntax, > and U-Boot makes it really trivial to use if you use the FIT image > format to have multiple overlays bundled in the same image. You can > choose to apply them dynamically, for example based on an EEPROM or > some other metric to see which combination you have. Ah, this is interesting. I'm going to experiment with that. > >>>>>> +&usb_otg { >>>>>> + dr_mode = "otg"; >>>>> >>>>> You're saying that this is a USB-A connector? Then it's not OTG since >>>>> it doesn't have an ID pin, this is an host. >>>> >>>> Right, with a special overlay I will activate Usb Device for RNDIS, >>>> so modified as host >>> >>> That doesn't really make much sense. The USB OTG is wired only using a >>> daughter board? >> >> My fault, I've meant "peripheral" in one case and "host" in another case. >> Usually "host". >> Are there problem with this? >> There is no daughter board. > > If you have an ID pin and the ability to control VBUS, then you don't > need to change the device tree, it's done automatically at runtime by > Linux. Unfortanetely I don't have ID pin and a common mosfet to control VBUS. "peripheral" mode should be used only in debug mode, so right dt-overlay can be written to sd-card by ourself or some of our customers. Thank you very much for all clarifications! Giulio. > > Maxime >
Hi Maxime, >> You don't have to handcode the fragments anymore with the new syntax, >> and U-Boot makes it really trivial to use if you use the FIT image >> format to have multiple overlays bundled in the same image. You can >> choose to apply them dynamically, for example based on an EEPROM or >> some other metric to see which combination you have. > > Ah, this is interesting. I'm going to experiment with that. > I'm struggling against this, I don't really know how to proceed, except keeping monolithic dts files including other dtsi files. About dt-overlays I've tried to look around lot of time, but the only thing I've found is this: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays where they use .dtso tagging them as "/plugin/;" and compile all .dtso found in dts folder. Then they obtain .dtbo files that should be the dt-overlays we have spoken about right? What I can't understand is if there's a real standard at this time to follow, because on renesas-driver they use their way to handle all .dtso files, but on mainline there seems to be nothing about that. So at the moment I'm trying to compile dts tagged as /plugin/; but dtc gives me a lot of warnings. dts: " /dts-v1/; /plugin/; #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> &i2c2 { pinctrl-names = "default"; pinctrl-0 = <&i2c2_pins_a>; status = "okay"; ft5x { compatible = "edt,edt-ft5306"; reg = <0x38>; interrupt-parent = <&pio>; interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */ reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */ touchscreen-size-x = <480>; touchscreen-size-y = <272>; }; }; " Build output issuing make ARCH=arm CROSS_COMPILE=arm-linux- aaa.dtb (I use aaa.dts as source): " arch/arm/boot/dts/aaa.dtb: Warning (reg_format): /fragment@0/__overlay__/ft5x:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) arch/arm/boot/dts/aaa.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' arch/arm/boot/dts/aaa.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format' arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size): /fragment@0/__overlay__/ft5x: Relying on default #address-cells value arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size): /fragment@0/__overlay__/ft5x: Relying on default #size-cells value " Then in uboot I'm trying to do as follows: # fdt addr 0x43000000 (where dtb is) # fdt resize 8192 # fdt apply 0x430c0000 (where dtbo is) But it gives me "libfdt fdt_check_header(): FDT_ERR_BADMAGIC" (I was expecting some error) Is there anywhere a guide for this? Is this what you've meant before? Using FIT for my use is not the best, so I would like to have many overlays in /boot folder and use different boot.scr depending on hardware. Can you point me to somewhere or something? I don't really know where to beat my head! Thanks in advance.
Hi, On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: > > > You don't have to handcode the fragments anymore with the new syntax, > > > and U-Boot makes it really trivial to use if you use the FIT image > > > format to have multiple overlays bundled in the same image. You can > > > choose to apply them dynamically, for example based on an EEPROM or > > > some other metric to see which combination you have. > > > > Ah, this is interesting. I'm going to experiment with that. > > > > I'm struggling against this, I don't really know how to proceed, > except keeping monolithic dts files including other dtsi files. > > About dt-overlays I've tried to look around lot of time, > but the only thing I've found is this: > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays > > where they use .dtso tagging them as "/plugin/;" > and compile all .dtso found in dts folder. > Then they obtain .dtbo files that should be the dt-overlays we have spoken > about right? Yes. You don't have to do that though, you can just rely on dtc to compile them, outside of the linux build system. > What I can't understand is if there's a real standard at this time to > follow, because on renesas-driver they use their way to handle all .dtso > files, but on mainline there seems to be nothing about that. I'm not sure what you mean here. It's just fragments of device tree, that have to be compiled using dtc, that's it. You can use the Linux build system infrastructure to do that, or you can build your own simpler one. That's really up to you. See for example https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile (even though the overlays themselves use the legacy syntax and shouldn't really be used an examples) > So at the moment I'm trying to compile dts tagged as /plugin/; > but dtc gives me a lot of warnings. > > dts: > " > /dts-v1/; > /plugin/; > > #include <dt-bindings/gpio/gpio.h> > #include <dt-bindings/interrupt-controller/irq.h> > > &i2c2 { > pinctrl-names = "default"; > pinctrl-0 = <&i2c2_pins_a>; > status = "okay"; > > ft5x { > compatible = "edt,edt-ft5306"; > reg = <0x38>; > interrupt-parent = <&pio>; > interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */ > reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */ > touchscreen-size-x = <480>; > touchscreen-size-y = <272>; > }; > }; > " > > Build output issuing make ARCH=arm CROSS_COMPILE=arm-linux- aaa.dtb (I use > aaa.dts as source): > " > arch/arm/boot/dts/aaa.dtb: Warning (reg_format): > /fragment@0/__overlay__/ft5x:reg: property has invalid length (4 bytes) > (#address-cells == 2, #size-cells == 1) > arch/arm/boot/dts/aaa.dtb: Warning (pci_device_bus_num): Failed prerequisite > 'reg_format' > arch/arm/boot/dts/aaa.dtb: Warning (simple_bus_reg): Failed prerequisite > 'reg_format' > arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size): > /fragment@0/__overlay__/ft5x: Relying on default #address-cells value > arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size): > /fragment@0/__overlay__/ft5x: Relying on default #size-cells value > " Yeah, your i2c node doesn't have the right address-cells and size-cells properties value, like dtc is telling you. > Then in uboot I'm trying to do as follows: > # fdt addr 0x43000000 (where dtb is) > # fdt resize 8192 > # fdt apply 0x430c0000 (where dtbo is) > But it gives me "libfdt fdt_check_header(): FDT_ERR_BADMAGIC" > (I was expecting some error) It looks like your overlay hasn't been properly loaded. Maxime
Hi Maxime! Il 04/05/2018 10:06, Maxime Ripard ha scritto: > Hi, > > On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: >>>> You don't have to handcode the fragments anymore with the new syntax, >>>> and U-Boot makes it really trivial to use if you use the FIT image >>>> format to have multiple overlays bundled in the same image. You can >>>> choose to apply them dynamically, for example based on an EEPROM or >>>> some other metric to see which combination you have. >>> >>> Ah, this is interesting. I'm going to experiment with that. >>> >> >> I'm struggling against this, I don't really know how to proceed, >> except keeping monolithic dts files including other dtsi files. >> >> About dt-overlays I've tried to look around lot of time, >> but the only thing I've found is this: >> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays >> >> where they use .dtso tagging them as "/plugin/;" >> and compile all .dtso found in dts folder. >> Then they obtain .dtbo files that should be the dt-overlays we have spoken >> about right? > > Yes. You don't have to do that though, you can just rely on dtc to > compile them, outside of the linux build system. > >> What I can't understand is if there's a real standard at this time to >> follow, because on renesas-driver they use their way to handle all .dtso >> files, but on mainline there seems to be nothing about that. > > I'm not sure what you mean here. It's just fragments of device tree, > that have to be compiled using dtc, that's it. You can use the Linux > build system infrastructure to do that, or you can build your own > simpler one. That's really up to you. See for example > https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile > > (even though the overlays themselves use the legacy syntax and > shouldn't really be used an examples) Everything works now! Thank you very much! I've setted up a Repo on Github to give an example on how make it work with no pain: https://github.com/micronovasrl/linova-dtoverlays At the moment it's a mess all around, but it's working and give an idea on how to make it work. Though I'm going to clean it up well as a base for linova dtoverlays. Ah, btw, can you confirm me that base dts file must be compiled outside kernel with: dtc -@ .... Otherwise as in-tree dts with make dtbs "-@" argument is not passed. Right? Thank you a lot for your help and time again! Best regards!
Hi, Giulio, On 05/05/2018 12:52 AM, Giulio Benetti wrote: > Hi Maxime! > > Il 04/05/2018 10:06, Maxime Ripard ha scritto: >> Hi, >> >> On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: >>>>> You don't have to handcode the fragments anymore with the new syntax, >>>>> and U-Boot makes it really trivial to use if you use the FIT image >>>>> format to have multiple overlays bundled in the same image. You can >>>>> choose to apply them dynamically, for example based on an EEPROM or >>>>> some other metric to see which combination you have. >>>> >>>> Ah, this is interesting. I'm going to experiment with that. >>>> >>> >>> I'm struggling against this, I don't really know how to proceed, >>> except keeping monolithic dts files including other dtsi files. >>> >>> About dt-overlays I've tried to look around lot of time, >>> but the only thing I've found is this: >>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays >>> >>> >>> where they use .dtso tagging them as "/plugin/;" >>> and compile all .dtso found in dts folder. >>> Then they obtain .dtbo files that should be the dt-overlays we have >>> spoken >>> about right? >> >> Yes. You don't have to do that though, you can just rely on dtc to >> compile them, outside of the linux build system. >> >>> What I can't understand is if there's a real standard at this time to >>> follow, because on renesas-driver they use their way to handle all >>> .dtso >>> files, but on mainline there seems to be nothing about that. >> >> I'm not sure what you mean here. It's just fragments of device tree, >> that have to be compiled using dtc, that's it. You can use the Linux >> build system infrastructure to do that, or you can build your own >> simpler one. That's really up to you. See for example >> https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile >> >> (even though the overlays themselves use the legacy syntax and >> shouldn't really be used an examples) > > Everything works now! > Thank you very much! > I've setted up a Repo on Github to give an example on how make it work > with no pain: > https://github.com/micronovasrl/linova-dtoverlays > > At the moment it's a mess all around, but it's working and give an > idea on how to make it work. Though I'm going to clean it up well as a > base for linova dtoverlays. > > Ah, btw, can you confirm me that base dts file must be compiled > outside kernel with: > dtc -@ .... > Otherwise as in-tree dts with make dtbs "-@" argument is not passed. > Right? > > Thank you a lot for your help and time again! > > Best regards! > I'd highly recommend you to look at Armbian overlay support: it is easy and elegant. https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-overlay-compilation-support.patch https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-sunxi-overlays.patch Sergey
Hi Sergey, Il 04/05/2018 23:59, Sergey Suloev ha scritto: > Hi, Giulio, > > On 05/05/2018 12:52 AM, Giulio Benetti wrote: >> Hi Maxime! >> >> Il 04/05/2018 10:06, Maxime Ripard ha scritto: >>> Hi, >>> >>> On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: >>>>>> You don't have to handcode the fragments anymore with the new syntax, >>>>>> and U-Boot makes it really trivial to use if you use the FIT image >>>>>> format to have multiple overlays bundled in the same image. You can >>>>>> choose to apply them dynamically, for example based on an EEPROM or >>>>>> some other metric to see which combination you have. >>>>> >>>>> Ah, this is interesting. I'm going to experiment with that. >>>>> >>>> >>>> I'm struggling against this, I don't really know how to proceed, >>>> except keeping monolithic dts files including other dtsi files. >>>> >>>> About dt-overlays I've tried to look around lot of time, >>>> but the only thing I've found is this: >>>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays >>>> >>>> >>>> where they use .dtso tagging them as "/plugin/;" >>>> and compile all .dtso found in dts folder. >>>> Then they obtain .dtbo files that should be the dt-overlays we have >>>> spoken >>>> about right? >>> >>> Yes. You don't have to do that though, you can just rely on dtc to >>> compile them, outside of the linux build system. >>> >>>> What I can't understand is if there's a real standard at this time to >>>> follow, because on renesas-driver they use their way to handle all >>>> .dtso >>>> files, but on mainline there seems to be nothing about that. >>> >>> I'm not sure what you mean here. It's just fragments of device tree, >>> that have to be compiled using dtc, that's it. You can use the Linux >>> build system infrastructure to do that, or you can build your own >>> simpler one. That's really up to you. See for example >>> https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile >>> >>> (even though the overlays themselves use the legacy syntax and >>> shouldn't really be used an examples) >> >> Everything works now! >> Thank you very much! >> I've setted up a Repo on Github to give an example on how make it work >> with no pain: >> https://github.com/micronovasrl/linova-dtoverlays >> >> At the moment it's a mess all around, but it's working and give an >> idea on how to make it work. Though I'm going to clean it up well as a >> base for linova dtoverlays. >> >> Ah, btw, can you confirm me that base dts file must be compiled >> outside kernel with: >> dtc -@ .... >> Otherwise as in-tree dts with make dtbs "-@" argument is not passed. >> Right? >> >> Thank you a lot for your help and time again! >> >> Best regards! >> > I'd highly recommend you to look at Armbian overlay support: it is easy > and elegant. > > https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-overlay-compilation-support.patch > > > https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-sunxi-overlays.patch Thanks for pointing me that, but as we've discussed before, at the moment overlays are not going to be included in Mainline Kernel(Maxime correct if I'm wrong). Try to think maintaining thousands and thousands of overlays, it would be a nightmare(IMHO). Maybe it will change, I don't know. Thanks anyway. Best regards
On Fri, May 04, 2018 at 11:52:59PM +0200, Giulio Benetti wrote: > Hi Maxime! > > Il 04/05/2018 10:06, Maxime Ripard ha scritto: > > Hi, > > > > On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote: > > > > > You don't have to handcode the fragments anymore with the new syntax, > > > > > and U-Boot makes it really trivial to use if you use the FIT image > > > > > format to have multiple overlays bundled in the same image. You can > > > > > choose to apply them dynamically, for example based on an EEPROM or > > > > > some other metric to see which combination you have. > > > > > > > > Ah, this is interesting. I'm going to experiment with that. > > > > > > > > > > I'm struggling against this, I don't really know how to proceed, > > > except keeping monolithic dts files including other dtsi files. > > > > > > About dt-overlays I've tried to look around lot of time, > > > but the only thing I've found is this: > > > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays > > > > > > where they use .dtso tagging them as "/plugin/;" > > > and compile all .dtso found in dts folder. > > > Then they obtain .dtbo files that should be the dt-overlays we have spoken > > > about right? > > > > Yes. You don't have to do that though, you can just rely on dtc to > > compile them, outside of the linux build system. > > > > > What I can't understand is if there's a real standard at this time to > > > follow, because on renesas-driver they use their way to handle all .dtso > > > files, but on mainline there seems to be nothing about that. > > > > I'm not sure what you mean here. It's just fragments of device tree, > > that have to be compiled using dtc, that's it. You can use the Linux > > build system infrastructure to do that, or you can build your own > > simpler one. That's really up to you. See for example > > https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile > > > > (even though the overlays themselves use the legacy syntax and > > shouldn't really be used an examples) > > Everything works now! > Thank you very much! > I've setted up a Repo on Github to give an example on how make it work with > no pain: > https://github.com/micronovasrl/linova-dtoverlays > > At the moment it's a mess all around, but it's working and give an idea on > how to make it work. Though I'm going to clean it up well as a base for > linova dtoverlays. > > Ah, btw, can you confirm me that base dts file must be compiled outside > kernel with: > dtc -@ .... > Otherwise as in-tree dts with make dtbs "-@" argument is not passed. > Right? You should use DTC_FLAGS='-@' Maxime
Hi, Il 07/05/2018 09:30, Maxime Ripard ha scritto: >> Otherwise as in-tree dts with make dtbs "-@" argument is not passed. >> Right? > > You should use DTC_FLAGS='-@' Thank you, I'm going to use that.
diff --git a/Documentation/devicetree/bindings/arm/micronova.txt b/Documentation/devicetree/bindings/arm/micronova.txt index 35c4127..9f5ac72 100644 --- a/Documentation/devicetree/bindings/arm/micronova.txt +++ b/Documentation/devicetree/bindings/arm/micronova.txt @@ -4,3 +4,7 @@ Micronova Device Tree Bindings A20-LiNova1-4_3 HMI Required root node properties: - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20"; + +A20-LiNova1-7 HMI +Required root node properties: + - compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20"; diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index c45a4f25..eafa7cb 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \ sun7i-a20-m3.dtb \ sun7i-a20-mk808c.dtb \ sun7i-a20-linova1-ctp-4_3i.dtb\ + sun7i-a20-linova1-ctp-7i.dtb\ sun7i-a20-olimex-som-evb.dtb \ sun7i-a20-olinuxino-lime.dtb \ sun7i-a20-olinuxino-lime2.dtb \ diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts new file mode 100644 index 0000000..7fd0d98 --- /dev/null +++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts @@ -0,0 +1,192 @@ +/* + * This is based on sun7i-a20-linova1-ctp-7i.dts + * + * Copyright 2014 - Hans de Goede <hdegoede@redhat.com> + * Copyright (c) 2014 FUKAUMI Naoki <naobsd@gmail.com> + * Copyright (c) 2018 Giulio Benetti <giulio.benetti@micronovasrl.com> + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file 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 file 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. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +/dts-v1/; +#include "sun7i-a20.dtsi" +#include "sunxi-common-regulators.dtsi" + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/interrupt-controller/irq.h> + +/ { + model = "Micronova srl LiNova1 CTP 7i"; + compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20"; + + aliases { + serial0 = &uart0; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + panel: panel { + compatible = "cdtech,s070wv95-ct16", "simple-panel"; + power-supply = <®_vcc3v3>; + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + panel_input: endpoint@0 { + reg = <0>; + remote-endpoint = <&tcon0_out_panel>; + }; + }; + }; +}; + +&ehci0 { + status = "okay"; +}; + +&ehci1 { + status = "okay"; +}; + +&i2c0 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c0_pins_a>; + status = "okay"; + + axp209: pmic@34 { + compatible = "x-powers,axp209"; + reg = <0x34>; + interrupt-parent = <&nmi_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + + interrupt-controller; + #interrupt-cells = <1>; + }; +}; + +&i2c2 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c2_pins_a>; + status = "okay"; + + ft5x: touchscreen@38 { + compatible = "edt,edt-ft5206"; + reg = <0x38>; + interrupt-parent = <&pio>; + interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */ + reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */ + touchscreen-size-x = <800>; + touchscreen-size-y = <480>; + }; +}; + +&mmc0 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc0_pins_a>; + vmmc-supply = <®_vcc3v3>; + bus-width = <4>; + cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */ + cd-inverted; + status = "okay"; +}; + +&ohci0 { + status = "okay"; +}; + +&ohci1 { + status = "okay"; +}; + +&otg_sram { + status = "okay"; +}; + +®_usb0_vbus { + status = "okay"; +}; + +®_usb1_vbus { + status = "okay"; +}; + +&uart0 { + pinctrl-names = "default"; + pinctrl-0 = <&uart0_pins_a>; + status = "okay"; +}; + +&usb_otg { + dr_mode = "otg"; + status = "okay"; +}; + +&usbphy { + pinctrl-names = "default"; + usb0_vbus-supply = <®_usb0_vbus>; + usb1_vbus-supply = <®_usb1_vbus>; + status = "okay"; +}; + +&be0 { + status = "okay"; +}; + +&de { + status = "okay"; +}; + +&tcon0 { + pinctrl-names = "default"; + pinctrl-0 = <&lcd0_rgb888_pins>; + status = "okay"; +}; + +&tcon0_out { + tcon0_out_panel: endpoint@0 { + reg = <0>; + remote-endpoint = <&panel_input>; + }; +};
The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production label, is an industrial Human Machine Interface. It features: - 512MB DDR RAM - 1 Sd-card >= 4GB - 1 Usb otg(programmable via software) with A-Usb Connector - 1 Usb host - 1 Buzzer - 1 Input for LiPo - 1 Relay to signal absence of power supply - 1 External Rtc with 56 bytes of ram + CR2032 battery - 1 7" 24-bits Tft 800x480 with PCap on - 1 Mono audio 1-watt amplifier - 1 RS485 port - 1 Power On Line through +12Vdc reaching 57.600baud, from where it can be supplied and placed in a network of 50 units - exposed jtag pins HMI is supplied from +12Vdc. Ethernet is absent, so for debugging, need to enable rndis on Usb otg port through an A-A usb cable. It comes in different flavours for connector types and can be found with umounted features as requested by customers. Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> --- .../devicetree/bindings/arm/micronova.txt | 4 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 +++++++++++++++++++++ 3 files changed, 197 insertions(+) create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts